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Introduction 



Purpose of this Publication 

This publication provides programmers with the in- 
formation necessary to write efficient programs using 
the Basic Input/Output Control System of the ibm 
1410/7010 Operating System. 

Purpose of the IOCS 

The Basic Input/Output Control System (hereafter 
referred to as the iocs) provides programmers with a 
tested, eflBcient means of scheduling, implementing, 
and controlling the transfer of data between specified 
input/output devices and 1410 or 7010 core storage. 

Specifically, the iocs can perform the following 
functions : 

1. Read data records or blocks of data records from 
the IBM 1402 Card Read Punch, 1442 Serial Card 
Reader, 1011 Paper Tape Reader, 729 and 7330 Mag- 
netic Tape Units, 1301 Disk Storage, 1311 Disk Stor- 
age, and 2302 Disk Storage. 

2. Write data records or blocks of data records on 
the IBM 1402 Card Read Punch, 1403 Printer, 729 and 
7330 Magnetic Tape Units, 1301 Dish Storage, 1311 
Disk Storage, and 2302 Disk Storage. 

3. Detect error conditions, and correct those error 
conditions that lend themselves to correction. 

4. Block and unblock data records. 

5. Overlap read/write and processing operations. 

6. Read, check, and write tape labels. 

7. Provide exits to user-written routines such as end- 
of~file routines. 

8. Detect Tele-processing interrupts and pass con- 
trol to the Tele-processing Supervisor so that such 
requests can be processed, 

9. Provide for automatic rewinding, rewinding and 
unloading, or backspacing of the various reels of tape 
files at specific points in the user's program. 

10. Detect Simultaneous Peripheral Operations On 
Line (spool) interrupts. 

Prerequisites 

It is assumed that readers of this publication have 
completed a basic course in programming the ibm 



1410 or 7010 Data Processing Systems, and are familiar 
with the information contained in the following pub- 
lications: 

IBM 1410/7010 Operating System; Basic Concepts, 
Form C28-0318. 

IBM 1410/7010 Operating System; System Monitor, 
Form C28-0319. 

IBM 1410/7010 Operating System; Autocoder, Form 
C28-0326. 



Minimum Machine Requirements 

The minimum machine requirements for programs in- 
corporating the iocs are contained in the publication, 
IBM 1410/7010 Operating System; System Generation, 
Form C28-0352. 



Definition of Terms 

Basic terms that appear frequently in this publication 
are defined here for the convenience of the reader. 

Data Record: A collection of related facts, numbers, 
letters, or symbols that are treated as a unit and may 
be processed or produced by a computer. 
Logical Record: A data record. 
Card, Tape, Disk, and Printer Records: One or more 
data records brought together in such a way that they 
may be read or written by a single input/output in- 
struction. 
Physical Record: A card, tape, disk, or printer record. 
Data File: A group of data records brought to- 
gether for a specific purpose, such as grouping a com- 
pany's accounts receivable. 

Tape, Disk, Card Read, Card Punch, and Printer 
Files: Data files that are read from or written on, re- 
spectively, tape, disk, card read, card punch, or printer 
input/output devices. 

Input and Output Files: Data Files from which data 
records are read (input), or on which data records are 
written (output). 
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Basic Use of the IOCS 



The purpose of this section is to provide the informa- 
tion necessary to write efficient programs that make 
use of the functions of the iocs outlined under "Pur- 
pose of the iocs" in the introduction to this publication. 
It should be noted, however, that the iocs is capable 
of providing additional or expanded functions. These 
additional functions are discussed in a later section 
entitled "Extended Use of the iocs." 



IOCS Check List 

Whether the programmer wishes to take advantage 
of the basic functions of the iocs, or the basic functions 
plus selected additional functions, the following con- 
ditions must be met if the iocs is to be used: 

1. The configuration of the Resident iocs must be 
defined at System Generation by means of the iokdf 
macro-instruction and one or more devdf macro-in- 
structions; or by means of the iokdf macro-instruction, 
one or more devdf macro-instructions, and one or more 
DSKDF macro-instructions. (The iokdf, devdf and dskdf 
macro-instructions are covered in the System Genera- 
tion publication.) 

2. Each data file that is to be processed by the 
object program must be defined by means of a dtf 
statement included in the source program. (The dtf 
statement is discussed later in this publication.) 

3. Every input/output area that is to be used by 
the object program must be defined by means of an 
Autocoder da (Define Area) statement included in the 
source program. (Input/output areas are discussed 
later in this pubHcation. da statements are covered in 
detail in the Autocoder publication, and discussed, as 
they pertain to the iocs, later in this pubHcation.) 

4. All user-written routines (e.g., end-of-file rou- 
tines) that are to be referenced by the object program 
must be written and included in the source program. 
(The DTF statement entries that inform the iocs of the 
existence of the various user-written routines, and the 
routines themselves, are discussed later in this pub- 
lication.) 

5. The specific functions the iocs is to perform dur- 
ing execution of the object program must be requested 
by means of iocs macro-instructions included in the 
source program. (The iocs macro-instructions are dis- 
cussed later in this publication.) 



General Information 

Information of a general nature, the understanding of 
which is considered a prerequisite to this discussion of 
a basic use of the iocs, is presented here. The material 
covered includes: record forms acceptable to the iocs, 
standard tape labels, input/output areas, da statements, 
blocking and unblocking, work areas and indexing, 
end-of-file determination, and wrong-length-record 
checking. 

Blocked Records 

Data records should be grouped in blocks when they 
are frequently read or written and are not excessive 
in length, because blocked records can be read and 
written at a faster rate than unblocked records. This 
is because the number of times a tape drive must be 
started and stopped and the number of times disk 
operations must be executed, to read or write a given 
number of data records, is reduced when the records 
are blocked. Furthermore, the reduction in the num- 
ber of tape interrecord gaps and disk record addresses 
permitted by blocked records increases the available 
storage capacity of a reel of tape or track of disk 
storage. 

Blocking and Unblocking 

The IOCS is capable of making data records that have 
been read into core storage in blocks available to the 
user's program as individual records (i.e., unblocking 
them). 

The IOCS is also capable of grouping individual data 
records (i.e., blocking them) for transfer from core 
storage. 

Record Forms Acceptable to the IOCS 

The IOCS accepts four forms of data records, under the 
following conditions: 

1. Records of the same file must have the same form, 
although the iocs is capable of handling several files 
each of which uses a different record form. 

2. Records moved from one area of core storage to 
another by the iocs must terminate with a record 
mark, or the area from which the record is moved must 
terminate in a group mark with word mark. 

The four forms of data records acceptable to the 
IOCS are Form 1, 2, 3, and 4 data records. 

Note: For descriptions and illustrations of the 
standard record forms as used with 1311 Disk Storage, 



see the publication IBM 1410/7010 Operating System; 
Support of IBM 1311 Disk Storage Drives Under the 
Operating System, Form C28-0402. 

FORM 1 DATA RICCORDS 

Form 1 records are unblocked, fixed-length or variable- 
length records. Form 1 records should be used when- 
ever: 

1. Data records are exceptionally long. 

2. Data records use a nonstandard format. 

3. The programmer plans to block data records 
himself prior to transferring them from core storage. 

4. The programmer does not wish to have wrong- 
length-record checks performed on unblocked, vari- 
able-length data records. 

Examples of Form 1 records, as they appear on 
magnetic tape and in disk storage, are shown in Figures 
1 and 2. 
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Unblocked, Fixed-Length Data Records, with Record Marks 
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Unblocked, Variable-Length Data Records, without Record Marks 
Figure 1. Form 1 Data Records on Magnetic Tape 

Note: The disk track formats shown in Figures 2, 4, 
6, and 8 are read or written by the Read/Write Full 
Track With Home Address or the Read/Write Single 
Record instruction. These formats were chosen arbi- 
trarily to simplify the figures. The programmer may 
format his disk tracks to be read or written by any 
1301 or 2302 read/write instruction. 

FORM 2 DATA RECORDS 

Form 2 records are blocked, fixed-length records. They 
should be used whenever data records are the same 



length. Examples of Form 2 records, as they appear 
on magnetic tape and in disk storage, are shown in 
Figures 3 and 4. 
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Blocked, Fixed-Length Data Records, with Record Marks 
Figure 3. Form 2 Data Records on Magnetic Tape 

FORM 3 DATA RECORDS 

Form 3 records are identical to Form 1 records, with 
one exception. The first four positions of every Form 3 
record contain a Block . Character-Count. This count 
allows the iocs to make wrong-length-record checks. 
When a Form 3 record is placed in an output area for 
transfer from core storage, the programmer must insert 
a group mark with word mark immediately to the 
right of the low-order position of the record, unless the 
low-order position coincides with the end of the output 
area. Examples of Form 3 records, as they appear on 
magnetic tape and in disk storage, as shown in Figures 
5 and 6. 

Block Character-Count: The Block Character-Count 
is a four-position field that must appear at the begin- 
ning of each Form 3 data record (See Figure 5) and 
at the beginning of each block of Form 4 data records 
(see Figure 7). This field contains an integer (right- 
justified) that specifies the number of positions of core 
storage required to contain the record or block of 
records. The positions occupied by the Block Char- 
acter-Count and any terminal record marks that ap- 
pear in the record or block of records are included in 
this number. Word marks may not appear over the 
three low-order positions of this field. 

FORM 4 DATA RECORDS 

Form 4 records are blocked, variable-length records 
that contain a Record Character-Count. In addition, 
the first four positions of each block of Form 4 records 
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Figure 2. Form 1 Data Records in 1301 or 2302 Disk Storage 
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Blocked, Fixed-Length Data Records, with Record Marks (Full Track) 

Figure 4. Form 2 Data Records in 1301 or 2302 Disk Storage 
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Figure 5. Form 3 Data Records on Magnetic Tape 



contain a Block Character-Count. (Form 4 records 
written by iocs have a plus sign in the junior position 
of the Block Character-Count. ) This record form should 
be used when a file consists of a large number of rec- 
ords that vary considerably in length. When a complete 
block of Form 4 records has been assembled in an out- 
put area for transfer from core storage, the iocs places 
a group mark with word mark immediately to the 
right of the low-order position of the block. 

Examples of Form 4 records, as they appear on mag- 
netic tape and in disk storage, are shown in Figures 
7 and 8. 

Record Character-Count: The Record Character- 
Count is a field consisting of from one to five positions 
that must appear in every Form 4 data record handled 
by the iocs (see Figure 7). The field contains an in- 
teger (right-justified) that specifies the number of posi- 
tions of core storage required to contain the record. 



The positions occupied by the Record Character-Count 
and the record mark terminating tiie record (if any) 
are included in this number. This field must have a 
word mark over its high-order position, unless it is five 
positions in length. Word marks cannot appear over 
any other position. The low-order position of this field 
must appear at a fixed distance from the I>igh-order 
position of each record in the file, and it cannot be 
signed minus. 
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Figure 7. Form 4 Data Records on Magnetic Tape 



RECORD FORM SUMMARY 

The four forms of data records acceptable to the iocs 
are summarized in Figure 9. 



Standard Tape Labels 

Optional tape label routines have been included in the 
IOCS to ensure that the correct tapes are made available 
to using programs, and to facilitate the maintenance 
of tape libraries. These tape label routines are based 
on use of 1410 80-character or ibm Standard 120-Char- 
acter header and trailer labels. Header labels are the 
first record on each reel of tape, and serve to identify 
the tape. Trailer labels are, except for a tape mark, the 
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Figure 6. Form 3 Data Records in 1301 or 2302 Disk Storage 
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Blocked, Variable-Length Data Records with Block Character Count, 
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Figure 8. Form 4 Data Records in 1301 or 2302 Disk Storage 
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Figure 9. Record Form Summary 



last record on each reel of tape. They indicate whether 
or not a reel is the last reel of a file. The formats of the 
1410 80-character and ibm Standard 120-Character 
header and trailer labels are discussed in the material 
that follows. 

1410 80-CHARACTER TAPE LABELS 

80-Character Temporary Header Labels: An 80-char- 
acter temporary header label should appear on each 
reel of tape that is to become part of a file that uses 
1410 80-character labels. The 80-character temporary 
header labels must conform to the format shown in 
Figure 10. 



Creation Date. The creation date (Field 4) is a five- 
digit number. The first two digits of this number specify 
the year; the remaining digits the day of the year this 
label was placed on the reel. 

Field 5. This is a five-position field that contains 
blanks. 

Miscellaneous. Field 6 can be used to include other 
information relevant to the label. 

1410 80-Character Header Labels: The iocs can re- 
place 80-character temporary header labels with 1410 
80-character header labels during execution of the 
user's object program. The 1410 80-character header 
labels must conform to the format shown in Figure 11. 



Field No. 


Positions 


Contents 


Description 


1 


1-5 


IHDRb 


Label Identifier 


2 


6-10 


xxxxx 


Reel Serial Number 


3 


n-30 


Blanks 




4 


31-35 


YYDDD 


Creation Date 


5 


36-40 


Blanks 




6 


41-80 


Miscellaneous 


May be used to include other 
pertinent information 



Figure 10. 1410 80-Character Temporary Header Label Format 

Label Identifier. The label identifier (Field 1) con- 
sists of the characters iHDRb. The label identifier indi- 
cates to the IOCS that the record containing these 
characters is a tape headc^r label. 

Reel Serial Number. The reel serial number (Field 
2) is a five-digit number that is assigned to the reel 
when it enters the tape library of the using installation. 

Field 3. This is a 20position field that contains 
blanks. 



Field No. 


Positions 


Contents 


Description 


1 


1-5 


IHDRb 


Label Identifier 


2 


6-10 


xxxxx 


Reel Serial Number 


3 


11-15 


xxxxx 


File Serial Number 


4 


16-20 


-xxxb 


Reel Sequence Number 


5 


21-30 


xxxxxxxxxx 


File Identification 


6 


31-35 


YYDDD 


Creation Date 


7 


36-40 


-xxxb 


Retention Period 


8 


41-80 


Miscellaneous 


May be used to include other 
pertinent information 



Figure 11. 1410 80-Character Header Label Format 



Label Identifier. The label identifier (Field 1) con- 
sists of the characters iHDRb. The label identifier in- 
dicates to the IOCS that the record containing these 
characters is a tape header label. 

Reel Serial Number. The reel serial number (Field 
2) is a five-digit number that is assigned to the reel 
when it enters the tape library of the using installation. 
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File Serial Number. The file serial number (Field 
3) is a five-digit integer that is equal to the reel serial 
number of the first reel of the file. 

Reel Sequence Number. The reel sequence number 
(Field 4) is a three-digit number preceded by a hyphen 
and followed by a blank character. It identifies the 
position within the tape file of this particular reel of 
the file (e.g., -007b appearing in this field would in- 
dicate that the reel is the seventh reel of the file). 

File Identification. The file identification (Field 5) 
consists of ten characters, and serves to identify the 
tape file to which the reel belongs. 

Creation Date. The creation date (Field 6) is a five- 
digit number. The first two digits specify the year; the 
remaining digits the day of the year the label was 
placed on the reel. 

Retention Period. The retention period (Field 7) is 
a three-digit number preceded by a hyphen and fol- 
lowed by a blank character. The three-digit number 
is the number of days the file is to be retained after 
the creation date appearing on the same reel. The iocs 
can process retention periods of up to 998 days for this 
type of label. If a file is to be protected beyond this 
time, 999 should be placed in this field. 

Miscellaneous. Field 8 may be used to include other 
information relevant to the label. 

1410 80-Character Trailer Labels: The 1410 80-char- 
acter trailer labels must conform to the format shown 
in Figure 12. 



Ffeld No. 


Positions 


Contents 


Description 


1 

2 
3 


1-5 

6-10 
11-80 


lEORb 

(or) 
lEOFb 
xxxxx 
Miscellaneous 


Trailer-Label Identifier 

Block Count 

May be used to include other 

pertinent information 



Figure 12. 1410 80-Character Trailer Label Format 

Label Identifier. The label identifier (Field 1) con- 
sists of the characters lEorb if the reel is the last reel 
of the file, or koRb if the reel is not the last reel. 

Block Count. The block count (Field 2) is the num- 
ber of blocks of data records that appear on the reel 
of tape. 

Miscellaneous. Field 3 may be used to include other 
information relevant to the label. 

IBM STANDARD 120-CHARACTER TAPE LABELS 

120-Character Temporary Header Labels: A 120- 
character temporary header label followed by a tape 
mark should appear on each reel of tape that is to 
become part of a data file that uses ibm Standard 120- 
Character /labels. These temporary header labels must 
conform to the format shown in Figure 13. 



Field No. 


Positions 


Contents 


Description 


1 


1-5 


fHDRb 


Label Identifier 


2 


6-10 


Blanks 




3 


11-15 


YYDDD 


Creation Date 


4 


16-30 


Blanks 




5 


31-35 


xxxxx 


Reel Serial Number 


6 


36-100 


Blanks 




7 


101-120 


Miscellaneous 


May be used to include other 
pertinent information 



Figure 13, ibm Standard 120-Character Temporary Header 
Label Format 



Label Identifier. The label identifier (Field 1) con- 
sists of the characters iHDRb. The label identifier indi- 
cates to the IOCS that the record containing these char- 
acters is a tape header label. 

Field 2. This is a five-position field that contains 
blanks. 

Creation Date. The creation date (Field 3) is a five- 
digit number. The first two digits specify the year; the 
remaining digits the day of the year this label was 
placed on the reel. 

Field 4. This is a 15-position field that contains 
blanks. 

Reel Serial Number. The reel serial number (Field 
5) is a five-digit number that is assigned to the reel 
when it enters the tape library of the using installation. 

Field 6. This is a 65-position field that contains 
blanks. 

Miscellaneous. Field 7 can be used to include in- 
formation relevant to the label. 

IBM Standard 120-Character Header Labels: The 
IOCS can replace 120-character temporary header labels 
with IBM Standard 120-Character header labels during 
execution of the user's object program. The ibm Stand- 
ard 120-Character header label must conform to the 
format shown in Figure 14. 

IBM Standard 120-Character Trailer Labels: The 
IOCS can write ibm Standard 120-Character trailer 
labels at the end of each reel of tape. The format of 
these trailer labels is identical to that of the ibm Stand- 
ard 120-Character header labels shown in Figure 14. 

Label Identifier. The label identifier (Field 1) con- 
sists of the characters iHDRb if the record is a header 
label; lEORb if the record is an end-of-reel trailer label; 
and lEOFb if the record is an end-of-file trailer label. 
The label identifier is followed by a blank in position 6. 

Retention Period. The retention period (Field 2) 
is a four-digit number (0001-9999) that represents the 
number of days the file is to be retained after the 
creation date specified in Field 3. 

Creation Date. The creation date (Field 3) is a five- 
digit number. The first two digits of this number specify 
the year, the remaining digits the day of the year the 
file, of which this reel is a part, was created. 
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Field No. 


Position 


Contenti 


Description 


1 


1-5 


IHDRb 








lEORb 
lEOFb 


Label Identifier 




6 


b 


Blank 


2 


7-10 


xxxx 


Retention Period 


3 


11-15 


YYDDD 


Creation Dote 


4 


16-25 


xxxxxxxxxx 


File Identification 


5 


26-30 


xxxxx 


File Serial Number 


6 


31-35 


xxxxx 


Reel Serial Number 




36 


b 


Blank 


7 


37-40 


xxxx 


Reel Sequence Number 




41 


b 


Blank 


8 


42-44 


bbb 


Reserved 


9 


45 


Not used 


Density Indicator 


10 


46 


Not used 


Checksum Indicator 


U 


47 


Not used 


Block Sequence Indicator 


12 


48 


Not used 


Tape Checking/Interpreting 
Technique Indicator 


13 


49 


Not used 


Tape Data Recording 
Technique Indicator 


14 


50 


Not used 


Tape Data Processing 
Technique Indicator 


15 


51-54 


xxxx 


Creating System 


16 


55 


X 


Record Format 


17 


56-60 


xxxxx 


Record Length 


18 


61-65 


xxxxx 


Block Size 


19 


66 


Not used 


Checkpoint Indicator 


20 


67-72 


xxxxxx 


Block Count 


21 


73-74 


bb 


Reserved 


22 


75-79 


bbbbb 


Reserved 


23 


80 


b 


Reserved 


24 


81-85 


bbbbb 


Reserved 


25 


86-91 


bbbbbb 


Reserved 


26 


92-100 


bbbbbbbbb 


Reserved 


27 


101-120 


Miscellaneous 


Any other pertinent information 



Figure 14, ibm Standard 120-Character Header/Trailer 
Label Format 



File Identification. The file identification (Field 4) 
consists of ten characters that identify the file to which 
the reel of tape belongs. 

File Serial Number. The file serial number (Field 5) 
is a five-digit integer equal to the reel serial number 
of the first reel of the file. 

Reel Serial Number. The reel serial number (Field 6) 
consists of five numerical characters assigned to the 
reel when it enters the tape library of the using instal- 
lation. This field is followed by a blank in position 36. 

Reel Sequence Number. The reel sequence number 
(Field 7) is a four-digit number that identifies the posi- 
tion within the tape file of this particular reel (e.g., 
0007 appearing in this field would indicate that this 
reel is the seventh reel of the file). 

Reserved. Field 8 is left blank. The three-position 
field is reserved for future ibm programming use. 

Density Indicator (Field 9), Check Sum Indicator 
(Field 10), Block Sequence Indicator (Field 11), Tape 
Checking/Interpreting Indicator (Field 12), Tape Data 
Recording Technique Indicator (Field 13), and Tape 
Data Processing Technique Indicator (Field 14). Fields 
9-14 are not applicable. 

Creating System. Field 15 is used to specify the 



Data Processing System on which the file was created. 
The IOCS enters 1410 or 7010 (whichever is applicable) 
in this field. 

Record Format. Field 16 is used to indicate the data 
record form used'by the file. Form 1, 2, 3, or 4 records 
are represented in this field by F, W, B, or X, respec- 
tively. 

Record Length. Field 17 is used to specify data 
record length. For fixed-length data records, the iocs 
enters the number of characters in each record. For 
variable-length records, the iocs enters the number of 
characters in the largest possible record. 

Block Size. Field 18 is used to specify block size. 
For blocked, fixed-length records, the iocs enters the 
number of data records in each block. For blocked, 
variable-length records, the iocs enters the maximum 
number of characters that can be contained in a block. 
If the file consists of unblocked records, this field 
contains blanks. 

Note: When writing tape labels, the iocs utilizes 
information provided in the dtf statements in entering 
the data for Fields 15 through 18. 

Checkpoint Indicator. This indicator (Field 19) is 
not applicable. The iocs enters zero in this field. 

Block Count. Field 20 is of significance only in trailer 
labels; it specifies the block count (i.e., the number of 
blocks of records on the reel). This count does not in- 
clude header labels, trailer labels, or tape marks. The 
field is six positions long; in a trailer label, the five 
right-most positions contain a five-digit count, and the 
high-order position always remains blank. In header 
labels the entire field is left blank. When writing trailer 
labels for the output file, the iocs enters in Field 20 
the number of blocks written. For an input file, the 
user /may, through the check entry, specify that the 
iocs match its count of the number of blocks read 
against the block count recorded in the trailer label. 

Reserved. Fields 21 through 26 are reserved for 
future IBM programming use. The iocs leaves these 
fields blank. 

Miscellaneous. Field 27 may include any informa- 
tion relevant to the label. 

When writing tape labels, the iocs takes information 
for Fields 2, 3, 4, and 5 from the dtf label entry; the 
IOCS increments the reel sequence number provided in 
the LABEL entry, when appropriate, to produce the 
number for the tape label of a new reel. The reel serial 
number is taken from the old header label on the out- 
put file tape. When reading tape labels from tapes con- 
taining the input file, the iocs can check any or all of 
Fields 2, 3, 4, 5, and 7 against data contained in the 
DTF CHECK entry, if that entry is used. When writing 
tape labels on the output file tape, the iocs can check 
the retention period for the old file if the user so speci- 
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fies via the check entry, this check is performed by 
adding the old header creation date and retention 
period and comparing the result with the current date. 

Standard Tape Formats 

When a tape file uses standard labels, the iocs can 
accept only the tape formats shown in Figure 15. 



Formaf A 


Format B 


120 Characl-er Header Label 


80 Character Header Label 


Tape Mark 
Data 
Tape Mark 


Data 

Tape Mark 

80 Character Trailer Label 


120 Character Trailer Label 


Tape Mark 


Tape Mark 





Figure 15. Tape Formats Acceptable to the iocs ( Standard 
Labels ) 

Input/Output Areas 

To read data records from or write data records on a 
data file, at least one input/output area must be pro- 
vided in core storage to contain the data records that 
have been read or that are to be written. 

The IOCS permits the programmer to specify more 
than one input/output area for each file so that he 
may take advantage of the Processing Overlap special 
feature. 

The number of input/output areas used for each file 
can have a direct bearing on the efficiency of the pro- 
gram. When selecting the number of areas that are to 
be used, the programmer should consider the follow- 
ing: 

1. Whether the program is input/output limited. If 
the program has to wait for input/output operations 
to provide records for processing or to write records 
that have already been processed, the use of multiple 
input/output areas can help reduce the running time 
of the program. 

2. The number of files in the program. If there are 
many files, the number of input/output areas specified 
per file may have to be limited to conserve core 
storage. 

3. The activity of the file. When the core storage 
available for input/output areas is limited, the major 
portion of that core storage should be allocated to 
areas that are to be used by the most active files. 

Single and multiple input/output areas are discussed 
separately, in the material that follows, to aid the user 
in selecting the most suitable number of areas for 
each file. 

ONE AREA 

When one input/output area is specified for a file, the 
program must ordinarily wait until an input/output 
operation has been executed before processing the next 



record. For this reason, the programmer should nor- 
mally avoid specifying a single area unless one or more 
of the following conditions apply: 

1. Core storage is limited by other program require- 
ments. 

2. The file does not contain many records. 

3. The file is seldom referenced by the program. 

4. The file is read from or written on a unit-record 
input/output device. 

5. The IOCS does not allow the use of more than one 
area. (Any such restriction is noted in the appropriate 
section of this manual.) 

MULTIPLE AREAS 

The pause to execute an input/output operation noted 
above can largely be eliminated by using multiple 
areas. When processing is completed in one area, the 
program begins processing the data record or records 
in the next area. At the same time, the iocs reads into, 
or writes out of the area in which processing was just 
completed. Under these conditions processing is virtu- 
ally continuous. 

DA (Define Area) Statements 

Autocoder da statements are used to reserve and define 
all input/output areas used by programs incorporating 
the IOCS. DA statements used to define input/output 
areas associated with unit-record or tape files (Figure 
16 ) must have the letter G preceded by a comma ( ,G ) 
in the operand field of the header line. This causes a 
group mark with word mark to be placed immediately 
to the right of the low-order position of the area. If an 
output file is to contain Form 2 records with record 
marks, the output area should be defined with record 
marks by placing an R or record mark as one of the 
operands in the da statement. An example of the area 
this statement will reserve in core storage is shown in 
Figure 17. 

Work Areas and Indexing 

If a file consist of blocked records or uses multiple 
input/output areas, the programmer must decide 
whether it is more economical to process each data 



Line 



&A^ 



Label 



Operation 



AREA 



M_ 



_2S_ 



JSL 



(e^tjner , opcr(Lir>ds) ^ Q, 



Figure 16. Unit-Record/Tape da Statement 



Data 



B-address 

Figure 17. Input/Output Areas ( Unit-Record/Tape Files ) 
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record in the input/output area(s) associated with the 
file by indexing the area(s), or to move each record into 
a work area and process it there. A general rule is 
available to guide the programmer. The number of 
positions of core-storage occupied by an input/output 
area associated with the relevant file should be divided 
by four. If the result is less than the number of indexed 
references required to process the data in that area, 
a work area should be used. If the result is greater, 
indexing should be used. 

End of File 

The IOCS determines that the end of a tape file has 
been reached when any of the conditions noted below 
has occurred. 

FILE TYPE CONDITION 

Tape Input The file makes use of standard trailer labels, 
and a lEorb trailer label identifier has been 
encountered on a reel of the file. 
Tape Input The file does not use labels, and a tape mark 
has been encountered on a reel of the file. 
Note: A tape mark causes end of file to be recog- 
nized, but does not cause checking of trailer labels (if 
any). If a file has standard trailer labels and a dtf 
CHECK entry with cnt or all operands is not specified, 
the trailer label will not be read. If the dtf check 
entry with a cnt or an all operand is specified, the 
trailer label will be read. Thus, an "end of file" caft be 
distinguished from an "end of reel." 

Wrong-Length Records 

The IOCS is capable of detecting wrong-length-record 
conditions. It performs this function, depending on 
the type of file, as follows: 

1. For disk files, the iocs checks the length of the 
record, as specified on the appropriate disk format 
track, against the size of the input/output area into 
which the record is read or from which it is written. 

2. For input files that consist of Form 1 (fixed-length 
only) or Form 2 data records, a check is made to deter- 
mine whether the interrecord gap following the record 
or block of records coincides with the group mark with 
word mark that terminates the input area into which 
the record or block was read. If the interrecord gap 
does not coincide with the group mark with word 
mark, a wrong-length-record condition is indicated. 
(The IOCS cannot make wrong-length-record checks for 
tape files consisting of unblocked, variable-length 
records that do not include a Block Character-Count.) 

3. For tape files that consist of Form 3 or Form 4 
data records, the iocs performs the wrong-length- 
record check by making reference to the Block Char- 
acter-Count that precedes the relevant record or block 
of records. A wrong-length-record condition is indi- 
cated if the length of the data record read or written 
is unequal to the Block Character-Count. 



4. For unit-record files, the iocs determines if the 
length of the relevant input/output area coincides 
with the size of the appropriate buffer in the ibm 1414 
Input/Output Synchronizer. 

DTF Statement 

The primary function of the dtf statement is to define 
the characteristics of the data file for which it was 
written. Each dtf statement consists of five or more 
entries. These entries may be broken down into those 
required for a basic use of the iocs and those required 
for an extended use of the iocs. The basic dtf entries 
are discussed in this section; the extended dtf entries 
are discussed in a later section. 

GENERAL FORMAT 

The DTF statement is written in the following manner. 
The code dtf is entered in the operation field of one 
line of the Autocoder coding sheet, and the name of 
the file that is to be defined is entered in the operand 
field of the same line. The entries relevant to this file 
are then listed on succeeding lines of the coding sheet. 
These entries must be selected from the entries dis- 
cussed in this section or in the section on the extended 
use of the iocs. As each entry is included, the opera- 
tion field of the affected line of the coding form must 
be left blank. Operands of the same entry must be 
separated by commas, unless otherwise noted in the 
discussion of that entry. Labels included as operands 
of an entry may be address modified. 

All entries may be followed by comments. These 
comments must be separated from the entries by a 
minimum of two consecutive blanks. 

There are no restrictions on where the dtf statement 
defining a particular file must appear in the user's 
source program. 

A DTF statement cannot be written for a file that 
refers to an input/output unit that has been designated 
the system's Standard Input Unit (siu). Alternate Input 
Unit (aiu). Standard Punch Unit (spu). Standard Print . 
Unit (spr), or System Operating File (sof). (See the 
System Monitor publication for a discussion of these 
units.) 

Basic DTF Entries 

The DTF entries required to make a basic use of the 
IOCS are as follows: 



DTF Header Line 

SYMUNIT 

FILEFORM 

BLOCKSIZE 

lOAREAS 

EOFADDR 

MODE 

ORDER 



RECSIZE 

INDEX 

PADCHAR 

ERRCHECK 

ERROPTNS 

RWDOPTNS 

LABEL 

CHECK 



DTF HEADER LINE 

This entry is required. It must appear as the first entry 
of every dtf statement. It consists of the code dtf 
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entered in the operation field of the coding sheet and 
the name of the data file that is to be defined entered 
in the operand field (see Figure 18). 



Line 
5 5 


Label 

6 IS 


Operation 

16 20 


21 25 30 


35 


J 


0,1, 


1 
1 , , , 


DT.F, . 


F,I.L.E,NAM,e / 


o,«, 


1 







Figure 18. dtf Header Line 

The name of the file cannot be a linkage symbol. 
(Linkage symbols are discussed in the System Monitor 
publication.) 

SYMUNIT 

This entry is required. The first operand of this entry 
indicates the type of input/output device used by the 
file. The first operand must be one of the following: 

OPERAND EXPLANATION 

1301 The file is read from or wrritten on 1301 Disk 

Storage. 
2302 The file is read from or written on 2302 Disk 

Storage. 
TAPE The file is read from or written on magnetic 

tape units. 
READER The file is read from a 1402 Card Read 

Punch or a 1442 Serial Card Reader. 
PUNCH The file is punched on a 1402 Card Read 

Punch. 
PRINTER The file is printed on a 1403 Printer. 
1011 The file is read from a 1011 Paper Tape 

Reader. 

The second operand of the symunit entry is the 
name of the symbolic unit that is to be used for the 
file. This name is used to assign a physical unit to the 
file. (See the System Monitor publication for discus- 
sions of symbolic units and physical units.) An example 
of how this entry is coded is shown in Figure 19. 
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3 5 
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6 


15 


Operation 
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Figure 19. symunit Entry 



FILEFORM 



This entry is required. The operand of this entry indi- 
cates the data record form used by the file. The oper- 
and must be 1, 2, 3, or 4 to indicate, respectively, Form 
1, 2, 3, or 4 data records. An example of how this entry 
is coded is shown in Figure 20. 



BLOCKSIZE 



This entry is required for files consisting of blocked 
records (Form 2 or Form 4). If Form 2 records are 
used, the operand of the blocksize entry should be the 
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Figure 20. fileform Entry 
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number of core-storage positions occupied by the data 
records in one block. If Form 4 records are used, the 
operand of the blocksize entry should be the maxi- 
mum block length desired; this number must reflect 
the four-position Block Character-Count, and must 
therefore be equal to or greater than the maximum 
data record length plus four. In the case of both Form 
2 and Form 4 records, the blocksize entry operand 
should not reflect the group mark with word mark 
terminating the input/output area. In addition, if the 
i/o medium involved is 1301 or 2302 disk storage, the 
blocksize entry operand should not reflect the number 
of core-storage positions occupied by the track address 
field or record address field, if either or both are pres- 
ent. Similarly, if the i/o medium involved is 1311 disk 
drive storage, the blocksize entry operand should not 
reflect the number of core-storage positions occupied 
by the disk control field. Figure 21 shows an example 
of how this entry is written. 



Line 

3 5 
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Operation 
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Figure 21. blocksize Entry 



lOAREAS 



This entry is required for a basic use of the iocs. It is 
used to indicate to the iocs which input/output areas 
are to be associated with the file. 

The lOAREAS entry may have a minimum of one, and 
a maximum of three operands. Each operand is the 
label of an input/output area that is to be associated 
with the file. The label must not be indexed. Figure 
22 shows an example of how this entry is written. 
Every input/output area whose label appears as an 
operand of this entry must be defined by an Auto- 
coder DA statement. (If the programmer wishes to use 
more than three input/output areas to process a file, 
he must utilize the dtf filelist entry. This entry is 
discussed under "Extended Use of the iocs.") 

The operand of the ioareas entry refers to the high- 
order position of the Track Address or Track/Record 
Address field. 
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Figure 22. ioareas Entry 



eofaddr 



This entry is required for all tape and unit-record 
input files. The operand of the eofaddr entry is the 
label of the end-of-file routine the programmer has 
provided for the file. (This routine is entered when- 
ever the iocs determines that an end-of-file condition 
has occurred on the file.) An example of how this entry 
is coded is shown in Figure 23. 




Figure 23. eofaddr Entry 



MODE 



This entry is required for files that are read or written 
in Load mode. It is also required for tape files that 
are read or written in odd parity. Two of the possible 
operands of the mode entry are load and odd. The 
LOAD operand indicates that the file is to be read or 
written in Load mode. The odd operand indicates that 
the file is to be read or written in odd parity. These 
operands may be entered in any order, and either 
operand may be omitted if it is not appropriate. See 
Figure 24 for an example of how this entry is written. 
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Figure 24. mode Entry 



ORDER 



This entry is required for all files except tape files, 
unless otherwise noted in the discussion of operands 
that follows. The operand of the order entry supplies 
the IOCS with the low-order character of the x-control 
field of the input/output instruction required to process 
the file. It must be one of the following: 

OPERAND EXPLANATION 

For input card files: 

0,1, or 2 Cards read from the file are to be selected into 
stacker 0, 1, or 2, respectively. (If stacker 1 is to be 
selected, the entry 1 may be omitted. 

For output card files: 

0, 4, or 8 Punched cards belonging to the file are to be selected 
mto stacker 0, 4, or 8, respectively. (If stacker 4 is 
to be selected, the entry 4 may be omitted.) 

For 1403 Printer files: 

^ T^*' Write A Line instruction is to be used to process 

the file. (If this instruction is chosen, the entry 
may be omitted.) 

1 The Write Word Marks instruction is to be used to 

process the file. 
For disk files, the file is to be read/ written using: 

1 The Read/Write Single; Record instruction. 

2 The Read/Write Full Track Without Record Ad- 
dresses instruction. (If this instruction is chosen, the 
entry 2 may be omitted.) 

5 The Read/Write Full Track With Home Address 
instruction. 

6 The Read/Write Full Track With Addresses instruc- 
tion. 

@ The Read/Write Cylinder instruction. 



The 1301 and 2302 Disk Storage inut/output in- 
structions are discussed in detail in the publication 
IBM 1301, Models 1 and 2, Disk Storage and IBM 
2302, Models 1 and 2, Disk Storage with IBM 1410 and 
7010 Data Processing Systems, Form A22-6788. 

An example of how the order entry is coded is 
shown in Figure 25. 
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Figure 25. order Entry 



RECSIZE 

This entry is only required for files that consist of Form 
2 or Form 4 records. If the file consists of Form 2 
records, the operand of the recsize entry specifies the 
number of characters that appear in each data record 
of the file. If the file consists of Form 4 records, the 
operand of the recsize entry specifies the position, in 
each data record, of the low-order digit of the Record 
Character-Count. (The first position of a Form 4 tape 
record is considered 1, not 0, when determining the 
position of the low-order digit of the Record Char- 
acter-Count.) An example of how this entry is coded 
is shown in Figure 26. 




Figure 26. recsize Entry 



INDEX 



This entry is required for a basic use of the iocs, if: 
(a) the file uses blocked records or multiple input/out- 
put areas, and (b) the programmer plans to access data 
records in the input/output areas associated with 
the file. 

The operand of the index entry is X1-X12, depend- 
ing on the index register ( 1-12) the programmer wishes 
to utilize. If this entry is included and the file is an 
input file, the iocs places, in the index register specified, 
the high-order address of the data record currently 
available to the using program. (See Figure 27.) 

If this entry is included and the file is an output 
file, the iocs places, in the index register specified, the 
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Figure 27. dtf index ( Input Files ) 
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high-order address of that portion of the current out- 
put area that is available to the using program. (See 
Figure 28.) 

At end of file, for blocked files, the index register 
points to the group mark with word mark following the 
input area. 

An example of how this entry is coded is shown 

in Figure 29. 

PADCHAR 

This entry is not required. It is relevant only if the file 
consists of blocked, fixed-length records (i.e., Form 2 
data records). The padchar entry (Figure 30) causes 
the IOCS to pad the last block of the file with the char- 
acter entered as the operand of this entry. The char- 



To be Made Available 



acter entered may be any character except 4=, ^, *» 
K, or,^, unless the file is to be sorted by the Generalized 
Tape Sort which is an integral part of the 1410/7010 
Operating System. In this case, the character entered 
as the operand of this entry must be the character 9. 
If this entry is omitted, the iocs pads with blank char- 
acters. (Blank characters are also acceptable to the 
Generalized Tape Sort.) 

EKRCHECK 

This entry is not required. It may be used to cause the 
IOCS to check for wrong-length records and/or to 
execute Write Disk Checks. The operands of the 
ERRCHECK entry, and the operations those operands 
cause the iocs to perform, are as follows: 
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Figure 28. dtf index (Output Files) 
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Figure 29. index Entry 
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Figure 30. padchar Entry 

OPERAND OPERATION 

WLR This operand causes the IOCS to check for 

wrong-length records. (It is recommended that 
this operand be specified for all input files, all 
unit-record output files, and all tape output files 
that consist of Form 3 or Form 4 records.) If 
this operand is omitted, the IOCS does not 
interrogate the Wrong-Length-Record channel 
status indicators. 

WDC This operand causes the IOCS to execute a 

Write Disk Check after every Write Disk op- 
eration performed on the file. 

One or both of these operands can be entered, and 
in any order. An example of how this entry is coded 
is shown in Figure 31. 
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Figure 31. errcheck Entry 



ERROPTNS 

This entry is not required. It should appear only if the 
file is an input file. It allows the programmer: (a) to 
accept all records read by input operations executed 
on the file that resulted in error conditions which the 
IOCS error procedures could not correct, or (b) to skip 
such records, llie operands of this entry are: 

OPERAND FUNCTION 

ACCEPT This operand causes the IOCS to handle all 
uncorrectable, erroneous records that occur 
on the file as if they were error free (i.e., re- 
lease them to the using program as the IOCS 
would a record read into core storage with- 
out error). 

SKIP This operand causes the IOCS to read the 

next physical record from the file into the 
input area that contains the uncorrectable, 
erroneous record, thereby destroying that 
record. 

If this entry is omitted, and a user-written error rou- 
tine has not been provided for the erroneous condi- 
tion, the IOCS will "accept" the erroneous records (i.e., 
process them as if they were error-free). 

Each of the operands discussed excludes the other. 
For this reason, only one may be specified in the same 
ERROPTNS entry. Figure 32 shows an example of how 
this entry is coded. 
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Figure 32. erroptns Entry 
RWDOPTNS 

This entry is not required. It is of significance only if 
the file is a tape file. This entry allows the program- 
mer to specify which reels of the file (if any) are to 
be rewound, rewound and unloaded, or backspaced — 
and at what point in the using program this action is 
to be taken. 

The operands of this entry indicate what action is 
to be taken. The operand fields in which these op- 
erands appear indicate which reels of the file are to 
be acted upon and the time at which this action (if 
any) is to be taken. The four operands that can appear 
in the operand fields of this entry are: 



OPERAND 
R 

u 



This operand causes the IOCS to rewind the 

tape reels indicated, at the time indicated. 

This operand causes the IOCS to rewind and 

unload the tape reels indicated, at the time 

indicated. 
B This operand causes the IOCS to backspace 

the tape reels indicated, at the time indicated. 
N This operand causes the IOCS to take no 

action on the tape reels indicated, at the time 

indicated. 

Note: If the character in an operand field is a letter 
other than an N (i.e., R, U, or B), the iocs moves the 
letter to the d-modifier position of a unit control in- 
struction. The instruction is used by the iocs to per- 
form the appropriate operation. 

The four operand fields of this entry are: 



OPERAND 
FIELD 

First 
Second 
Third 
Fourth 



AFFECTED REELS/tIME OF ACTION 

The first reel of the file is to be acted upon 

at the time the file is opened. 

Each reel of the file, except the first, is to be 

acted upon at the beginning of the reel. 

Each reel of the file, except the last, is to be 

acted upon at the end of the reel. 

The last reel of the file is to be acted upon 

at the time the file is closed. 

If this entry is included, all four operand fields must 
appear. They must not he separated by commas. 

If the file is a single-reel file, the second and third 
operand fields should contain N. 

If this entry is omitted, and the file is a tape file, 
the IOCS rewinds each reef of the file at the beginning 
and end of each reel. 

An example of how this entry is coded is shown in 
Figure 33. 
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Figure 33. rwdoptns Entry 
LABEL 

This entry is not required. It is relevant only if the 
file is a tape file that uses labels. The label entry pro- 
vides the IOCS with the following information: 

1. Whether the file uses 80-character or 120-char- 
acter labels. 

2. Whether the labels used by the file are standard 
(i.e., 1410 80-character or ibm standard 120-character 
labels) or nonstandard. 

3. The file serial number, file identification, retention 
period, creation date, and reel sequence number of the 
first reel of the file, if the file uses standard labels. 

The operands and operand fields of the label entry 
are as follows: 

OPERAND 

FIELD OPERAND 

First 80, if the file uses 80-character labels; 120 

if the file uses 120-character labels. 

Second The five-digit file serial number, if the file 

uses standard tape labels; NONSTD, if the 
file uses nonstandard labels. (If NONSTD is 
entered here, the rest of the operand fields 
of this entry that follow this field are left 
blank.) 

Third The file identification. If fewer than ten 

characters are entered, the IOCS left- justifies 
these characters and pads with blanks to ob- 
tain a ten-character file identification. 

Fourth The three-digit (80-character labels) or the 

four-digit (120-character labels) retention 
period. 

Fifth The five-digit creation date. 

Sixth The three-digit (80-character labels) or the 

four-digit (120-character labels) reel sequence 
number. 

If the file uses standard labels, all six of the operand 
fields discussed must appear in order. If the program- 
mer does not wish to enter the indicated operand in a 
particular operand field, he may omit that operand. 
However, the comma that would normally separate 
the omitted operand from the next operand (if any) 
must be included. An example of how this entry is 
written is shown in Figure 34. 

CHECK 

This entry is required only if the file uses labels and 
the IOCS is to check all or part of these labels. This 



entry indicates to the iocs what portions of these labels 
are to be checked. If this entry is omitted, the iocs 
does not check any portion of the labels used by the 
file. The operands, the label fields they cause the iocs 
to check, and the file type and label type affected by 
these operands are as follows: 
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Block count 


Input 
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Direct Compare* 



ALL All the above 
* Information provided by dtf label entry, updated by the 
IOCS where applicable, is compared against information read 
from the relevant label by the iocs. 

These operands can be entered in any order. The 
input trailer will be recognized only if the cnt or the 
all operand is specified. If neither is specified in the 
DTF CHECK entry for a file with trailer labels, the first 
tape mark will indicate end of file. If either bet or all 
is omitted, output file header labels are not read before 
creation of new header labels, and the reel serial num- 
ber fields in the new output header labels contain 
blanks. The reason for this is that the reel serial num- 
bers for new output headers are taken from the old out- 
put headers, which in this case are not read. An exam- 
ple of how this entry is coded is shown in Figure 35. 
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Figure 35. check Entry 
Sample DTF Statement 

The basic dtf statement for a representative tape file 
(e.g., a file that consists of Form 2 data records, uses 
1410 80-character labels, and is read or written in 
Move mode, even parity) is shown in Figure 36. 

IOCS Macro-Instructions 

The IOCS macro-instructions are Autocoder statements 
entered in the user's source program. When these 
macro-instructions are encountered by the Autocoder 
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Figure 34. label Entry 
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Figure 36. Representative dtf Statement 



processor, they cause the processor to produce 1410 or 
7010 mEichine-language instructions in the user's object 
program. These machine-language instructions cause 
the IOCS to perform one or more of the functions of 
which it is capable. 

The IOCS macro-instructions may be divided into 
those which cause the iocs to perform the basic func- 
tions discussed in the introduction to this publication 
and those which cause the iocs to perform additional 
or extended functions. The basic iocs macro-instruc- 
tions are covered in the raaterial that follows. The 
extended iocs macro-instructions are discussed under 
"Extended Use of the iocs." 

Note: All iocs macro-instructions destroy the status 
of the High, Low, Equal and Zero Balance Indicators, 
but do not aflFect the arithmetic overflow or divide 
overflow indicators. 

Basic IOCS Macro-Instructions 

The basic iocs macro-instnictions are: 

lOCTL OPEN, INPUT (Open Input File) 

lOCTL OPEN, OUTPUT (Open Output File) 

GET FILE (Make Next Logicd Record Available) 

GET FILE TO WORK (Make Next Logical Record Avail- 
able and Move to WORK) 

GET FILE TO FILE (Make Next Logical Record Available 
and Move to Output Area) 

PUT FILE (Write Logical Record) 

PUT WORK TO FILE (Move from WORK and Write 
Logical Record) 

PUT FILE TO FILE (Move from Input Area and Write 
Logical Record) 

lOCTL CLOSE, INPUT (Close Input File) 

lOCTL CLOSE, OUTPUT (Close Output File) 

General Functions 

Each of the basic iocs macro-instructions causes the 
IOCS to perform one or more general functions. These 
functions are discussed in the material that follows. 



lOCTL OPEN 

The lOCTL OPEN macro-instructions cause the iocs to 
perform the following functions: 

1. Link with the System Monitor to assign input 
and output files to the physical units specified for those 
files in the appropriate dtf symunit entries and asgn 
cards. (The asgn card is discussed in the System Moni- 
tor publication.) 

2. Rewind, rewind and unload, backspace, or take 
no action on the first reel of tape input and output 
files, according to the information supplied by the 
relevant dtf rwdoptns entries (if any). 

3. Read and check the header labels of tape input 
and output files, according to the information supplied 
by the appropriate dtf label and check entries. 

4. Make the first output area associated with output 
files available to the using program, and place the 
high-order address of the output areas made available 
in the index registers specified by the relevant dtf 
INDEX entries (if any). 



GET 



The GET macro-instructions cause the iocs to perform 
the following functions: 

1. Make the next logical record of the indicated file 
available to the using program in the area specified, 
unblocking the record when necessary. 

2. Schedule read operations to fill those input areas 
associated with the indicated files (if any) that have 
been processed by the using program. 

3. Begin processing any end-of-reel condition en- 
countered on the indicated file. 

4. Cause an exit to be taken to the end-of-file routine 
provided for the indicated file by the user, if the iocs 
determines that an end-of-file condition exists on that 
file. 
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PUT 

The PUT macro-instructions cause the iocs to perform 
the following functions: 

1. Prepare the current output area of the afiFected 
file to receive the next logical record of the file. 

2. Block data records in the current output area of 
the affected file. 

3. Schedule output operations that write on the 
affected file the data record(s) in the current output 
area of that file. 

4. Begin processing end-of-reel conditions encoun- 
tered on the affected file by branching to the iocs 
Output End-Of-Reel routine. 

5. Exit to the user's end-of-file routine for the affected 
file, if that file is a disk file and the iocs determines 
that an end-of-file condition exists on that file. 

lOCTL CLOSE 

The locTL CLOSE macro-instructions cause the iocs to 
perform the following functions: 

1. Ensure completion of all requests pending for 
input/output operations against input and output files. 

2. Pad incomplete blocks of Form 2 records if the 
affected files are output files. 

3. Write all remaining records or blocks of records 
(i.e., those records or blocks that have not already been 
written) from the output areas of output files. 

4. Write a tape mark on tape output files following 
the last data record or block of data records on those 
files. 

5. Assemble and write trailer labels for tape output 
files that include a dtf label or exten entry in the dtf 
statements used to define those files. 

6. Rewind, rewind and unload, backspace, or take 
no action on the last reel of tape input and output 
files, according to the information supplied by the ap- 
propriate DTF rwdoptns entries (if any). 

Using the Basic Macro-Instructions 

Figure 37 illustrates the use of ioctl open, get, put, 
and IOCTL close. 
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Figure 37. Basic Macro-Instructions 
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Figure 38. ioctl open, input 



IOCTL OPEN, OUTPUT 

This macro-instruction is used to open output data 
files. The names of the output files that are to be 
opened appear as the operands of this macro-instruc- 
tion. A maximum of eight files may be opened by 
each IOCTL open, output macro-instruction. Figure 39 
shows an example of how this macro-instruction is 
coded. 



Coding the Basic Macro-Instructions 

The basic iocs macro-instructions are coded as noted 
in the paragraphs that follow. 

IOCTL open, input 

This macro-instruction is used to open input data files. 
The names of the input files that are to be opened 
appear as the operands of this macro-instruction. A 
maximum of eight files may be opened by each ioctl 
open,input macro-instruction. An example of how this 
macro-instruction is coded is shown in Figure 38. 
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Figure 39. ioctl open, oxttput 



get file 

The GET FILE macro-instruction makes the next logical 
record from the affected file (e.g., the file labeled 
iNFiLE in Figure 40) available to the using program. 



20 



If a single input area has been specified for the file, 
the record is made available in that area. If multiple 
input areas are specified, the record is made available 
in the area with which the iocs is currently working. 
An example of how this macro-instruction is coded is 
shown in Figure 40. 
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Figure 40. get file 
GET FILE TO WORK 

The GET FILE TO WORK macro-iustruction, in addition to 
the functions described under "get file," causes the 
next logical record to be moved into an area other 
than an input area associated with the file (e.g., the 
area labeled work in the example of how this macro- 
instruction is coded, shown in Figure 41). 
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Figure 41. get file to work 

get file to file 

The get ptle to file macro-instruction, in addition to 
the functions described under "get file," causes the 
next logical record to be moved into an output area. 
If a single output area is specified for the aflFected file 
(e.g., the file labeled outfile in Figure 42), the record 
is moved into that area. If multiple output areas are 
specified, the record is moved into the area with which 
the IOCS is currently working. 

To use get file to file, the programmer must 
specify the dtf index entry for the affected output 
file, if the affected output file uses multiple output 
areas, or if the iocs is to build blocks of records in 
the output area(s) of that file. 

If the affected input and output files consist of Form 
4 data records, the next record is not immediately 
moved into the current output area. Under these con- 
ditions the IOCS first checks the current output area of 
the affected output file. If the area contains enough 
positions to absorb the record, the iocs then moves 
the record into the output area. If there are not enough 
positions, the contents of the output area are written 
on the affected output file, and the data record is moved 
into the output area as the first record of a new block. 

In either case, a put file must be issued against 
OUTFILE to cause the iocs: ( a) to account for the record 
just moved into the output area, and (b) to select the 
next available portion of the output area. 



Note: If this macro-instruction is used with two files, 
one that consists of Form 3 records and one that con- 
sists of Form 4 records: (a) the dtf recsize entry for 
the Form 4 file must have the character 4 as its oper- 
and, and ( b) the input area(s) associated with the Form 
3 file must have a word mark over its high-order posi- 
tion. 

An example of how this macro-instruction is coded 
is shown in Figure 42. 
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Figure 42. get file to file 
PUT FILE 

PUT FILE causes the iocs to write a data record, or a 
complete block of data records, on the affected file 
(e.g., the file labeled outfile in Figure 43). If a single 
output area was specified for the file, the record or 
block is written from that area. If multiple output areas 
were specified, the record or block is written from the 
output area with which the iocs is currently working. 
This macro-instruction can be used with files consist- 
ing of Form 4 records only when used in conjunction 
with PUT FILE, form4. ( See "put file, form4," under 
"Extended Use of the iocs.") An example of how this 
macro-instruction is coded is shown in Figure 43. 
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Figure 43. put file 
PUT WORK TO FILE 

PUT WORK TO FILE, in addition to the functions de- 
scribed under "put file," causes a data record in an 
area other than an input/output area (e.g., the area 
labeled work in Figure 44) to be moved to the cur- 
rent output area of the affected file (e.g., the file 
labeled outfile. An example of how this macro- 
instruction is coded is shown in Figure 44. 

put file to file 

PUT FILE to; file, in addition to the functions de- 
scribed und^r "put file," causes the current logical 
record in the current input area of the affected input 
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Figure 44. put work to file 
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file (e.g., the file labeled infile in Figure 45) to be 
moved into the current output area of the affected 
output file (e.g., the file labeled outfile in Figure 45). 

Note: If this macro-instruction is used with two 
files, one that consists of Form 3 records and one that 
consists of Form 4 records: (a) the dtf recsize entry 
for the Form 4 file must have the character 4 as its 
operand, and (b) the input/output area(s) associ- 
ated with the Form 3 file must have a word mark 
over its high-order position. 

To use PUT Fn.E to file, the programmer must 
specify the dtf index entry for the affected input file, 
if that file uses multiple input areas or consists of 
blocked records. 

An example of how this macro-instruction is coded 
is shown in Figure 45. 
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Figure 45. pvt file to file 



maximum of eight files may be closed by each ioctl 
CLOSE,iNPUT macro-instruction. Figure 46 shows an 
example of how the macro-instruction is coded. 
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Figure 46. ioctl close, input 
IOCTL CLOSE, OUTPUT 

This macro-instruction is used to close output data 
files. The names of the output files that are to be 
closed appear as the operands of this macro-instruc- 
tion. A maximum of eight files may be closed by each 
IOCTL CLOSE, OUTPUT macro-instructiou. Figure 47 shows 
an example of how this macro-instruction is coded. 
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Figure 47. ioctl close, output 



IOCTL CLOSE, INPUT 

This macro-instruction is used to close input data files. 
The names of the input files that are to be closed 
appear as the operands of this macro-instruction. A 



Note: No get or put macro-instruction should be 
issued against a file before the file is opened or after 
the file is closed by the appropriate ioctl macro- 
instruction. 
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Extended Use of the IOCS 



This section provides the information necessary to 
make use of the additional or extended capabiHties of 
the IOCS. These capabilities enable the iocs to: 

1. Use additional input/output areas to process a 
file. ( See the dtf ioareas, and filelist entries.) 

2. Provide exits to user-written error, service, and 
tape label routines. ( See, respectively, the dtf erraddr, 
iNTADDR, lineI, hne2 and lineI above entries, and the 
discussions of user-written error, service, and tape 
label routines.) 

3. Allow one File Table Extension to be used for 
more than one file. ( See the dtf exten entry.) 

4. Provide deferred forms of the get and put macro- 
instructions. ( See GET file, defer and put file, defer.) 

5. Provide an additional method of writing blocked 
variable-length records on output files. (See the dtf 
LENGTH entry and put file, form4.) 

6. Alter the stacker into which punched cards are 
to be selected during execution of the object program. 
(See PUT FiLE,d, put work to FiLE,d, and put file 

TO FILE,d,) 

7. Release partially processed blocks of data rec- 
ords. ( See lOCTL RELSE.) 

8. Force end-of-reel conditions. (See ioctl feor.) 

9. Write checkpoints. ( See ioctl chkpt.) 

10. Write specified areas of core storage on the 
console printer. ( See ioctl type, area and ioctl type, 

AREA, defer.) 

11. Perform certain input/output unit control func- 
tions, i.e., the rewinding or rewinding and unloading 
of tape reels. ( See the unctl macro-instructions.) 



Shared Files 

The Operating System can handle disk files that are 
shared by more than one central processing unit. For 
details see IBM 1410/7010 Operating System; System 
Generation, Form C28-0352. 



Extended DTF Entries 

The extended dtf entries may be broken down into 
basic entries with additional or extended operands 
and purely extended entries. These entries are listed 
below and discussed in the material that follows. 
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LINE2 
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MODE 

In addition to the operands discussed previously in 
this publication, a third operand may be included in 
this entry. This operand may be any Autocoder data 
move instruction mnemonic (e.g., mrcg). Figure 48 
shows an example of how this entry is coded. 
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Figure 48. mode Entry ( Third Operand ) 

If the file is a Load mode file, all data move in- 
structions generated as part of get or put macro- 
instruction calling sequences (i.e., the coding gen- 
erated by a GET or a put) that reference the file, are 
normally assembled as mrcwm move instructions. If 
the file is a Move mode file, all such data move instruc- 
tions are normally assembled as mrcm move instruc- 
tions. If the third operand of the mode entry is 
included, the Autocoder mnemonic entered as this 
operand is substituted for the move instruction nor- 
mally assembled (i.e., mrcwm or mrcm). 

If the third operand is included and one or both 
of the other operands (i.e., load and odd) are omitted, 
the comma (s) that would normally separate the omit- 
ted operand(s) from the next operand must be retained. 
( See Figures 49 and 50.) 
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Figure 49. mode Entry ( odd Omitted ) 
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Figure 50. mode Entry ( load and odd Omitted ) 
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ORDER 

The following characters, in addition to those dis- 
cussed previously, may appear as the operand of this 
entry: 

OPERAND EXPLANATION 

For input card files: 

9 The stacker into which cards read from the file are 

to be selected is to be specified during execution of 
the program by the UNCTL FILE,SSF,d macro- 
instruction. (If this operand is chosen, only one 
input/output area may be specified in the DTF 
lOAREAS entry.) 

For disk files: 

4 The Prevent Seek Complete instruction is to be gen- 

erated for the file.* 

7 The Write Format Track instruction is to be gen- 
erated for the file. 

8 The Set Access Inoperative instruction is to be gen- 
erated for the file.* 

9 The Release instruction is to be generated for the 
file.* 

NOTE : The usefulness of entries marked * is limited; 
they should be used with caution. 

The character entered as the operand of the order 
entry becomes the low-order character of the x-control 
field of all the input/output instructions generated 
for the file. These input/ouput instructions are con- 
tained in the iorw's (Input/Output Request Words) 
that are used to process the file, (iorw's are discussed 
under "Internal Operation of the iocs.") 

An example of how this entry is coded is shown in 
Figure 51. 
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Figure 51. obider Entry 



lOAREAS 



The lOAREAS entry causes the iocs to generate an In- 
put/Output Request Word (iorw) for each input/ 
output area whose label appears as an operand of the 
entry. The iocs uses the iorw's generated to schedule 
and implement input/output operations on the file. 
If the programmer plans to generate these iorw's, this 
entry is not required. 

The lOAREAS entry may have a fourth operand that 
was not covered in the previous discussion of the 
lOAREAS entry (see Figure 52). The fourth operand 
may be any label that consists of from one to nine 
alphameric characters. The iocs takes this label, adds 
the character A, B, or C, and assigns the modified 
label, respectively, to the first, second (if any), and 
third (if any) iorw generated by the other operands 
of this entry. This label will be the address of the low- 



order position of the Link Field in the iorw; the user 
can character-adjust the label to gain access to other 
IORW fields. 

If less than three input/output areas are specified 
by this entry, and labeling of the iorw's that are 
generated is desired, the comma(s) that would nor- 
mally separate the labels entered as the second and/or 
third operands must be included in the entry (see 
Figure 53). 
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Figure 52. ioareas Entry ( Four Operands ) 



Line 



0^ 



Label 



Operation 
!fi Jfi 



IQAREAS. 



-2£- 



_2fi_ 



-5JL 



_4fi_ 



I.QAR.E.A!.>.yv.LA.B.E.L 



>-^y 



-J I— J 1—1 1— 1_ 



D 



Figure 53. ioareas Entry ( Two Operands Omitted, Labeling 
Desired ) 

ERRCHECK 

In addition to the operands discussed earlier, this entry 
has two other possible operands (see Figure 55). 
They are: 

operand explanation 

STORE This operand causes the IOCS to store the 

contents of the E- or F-address register 
(whichever is appropriate) in the Address 
Register Field of the affected IORW after 
execution of the input/output instniction in 
the Input/Output Operation Field of the 
IORW. (iorw's are discussed under "In- 
ternal Operation of the IOCS.") 

This operand should not be specified if 
the file consists of variable-length records, 
and the WLR operand has been specified 
for the file. Under these conditions, the 
IOCS places the length of the last record 
read from the file in the Address Register 
Field of the relevant IORW, instead of the 
contents of the E- or F-address register. 
X This operand can be any single character. 

If this operand (hereafter referred to as the 
fourth operand) is included, it must always 
be the last operand of the ERRCHECK 
entry. This operand is used to prevent the 
IOCS from checking, after each input/output 
operation performed on the file, those chan- 
nel status indicators whose associated BCD 
bits are not included in the BCD code of 
the character entered. Extreme caution must 
be exercised when using the operand. The 
channel status indicators and their associated 
BCD bits are shown in Figure 54. 

Note: The iocs does not consider the Busy channel 
status indicator (i.e., 2 bit) an error indicator. If this 
indicator is on, the iocs does not indicate that an 
error condition exists on the relevant file. Instead, the 
IOCS immediately retries the aflfected input/ouput 
operation. 



24 



Channel Status 
Indicator 


Associated BCD 
Bit 


B 
A 
8 
4 
1 


Wrong-length record 
No Transfer 
Condition 
Data Check 
Not Ready 



Figure 54. Channel Status Indicators and Associated bcd Bits 
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Figure 55. errcheck Entry (Four Operands) 

If the fourth operand is omitted, the mtlr operand 
is included, and the file consists of Form 1 or Form 2 
records, the iocs checks all the channel status indi- 
cators. If this operand and the wlr operand are 
omitted, regardless of the record form used by the 
file, the IOCS checks all the channel status indicators 
except the Wrong-Length-Record indicator. 

If: (a) the fourth operand is used and its bcd code 
does not include the B bit, and ( b) the file consists of 
Form 1 or Form 2 records, the iocs does not interro- 
gate the Wrong-Length-Record indicator, even if the 
WLR operand has been specified. If the file consists of 
Form 3 or Form 4 records and the wlr operand was 
specified, the iocs makes a program check for wrong- 
length records by comparing the length of the record 
just read or written with the relevant Block Charac- 
ter-Count regardless of whether the fourth operand is 
used and whether it contains a B bit. If the fourth 
operand contains a B bit, the iocs will check the 
Wrong-Length-Record indicator regardless of the rec- 
ord form used. 

If the fourth operand is used and any of the other 
operands are omitted (i.e., wxr, vinoc, or store), the 
comma that would normally separate the omitted 
operand from the next succeeding operand must be 
included (see Figure 56). 
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Figure 56. errcheck Entry ( Two Operands Omitted, Fourth 
Included ) 

FILEFORM 

See Disk File Processing, pages 37-41. 

ERRADDR 

This entry is not required. It is used to specify the con- 
ditions under which the iocs is to exit to an error 
routine the programmer has provided for the file. 

The ERRADDR entry may have a minimum of one, and 
a maximum of six operands. The first operand is the 



label of the error routine the programmer has pro- 
vided for the file. (This operand may be omitted. If 
it is, the comma that would normally separate it from 
the next operand must be included in the entry.) 
Each of the second through sixth operands consists 
of a single character. The characters that may appear 
as these operands are shown in Figure 57. ( Acceptable 
characters for the second through sixth operands of an 
ERRADDR entry for a file on ibm 1311 Disk Storage can 
be found in Support of IBM 1311 Disk Storage Drives 
Under the Operating System.) 
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Condition (i.e., 1301 or 2302 Disk Storage Circuit Check, 
invalid Operation code, or Write Disk Check 
Without Mode setting) 
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Data Check (i.e.. Parity Check) 
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Data Check, No Transfer (i. e. , Invalid Track Number), or 
Data Check, No Transfer, andCond(i.e. , Mode Check) 
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No Transfer, Condition (i.e.. No Record Found, 
1301 or 2302 Disk Storage Circuit Check, or 
7631 File Control Circuit Check) 
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Condition (i .e ., 1 301 or 2302 Disk Storage Circuit Check) 
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Wrong Length Record, Condition (i.e., 1301 or 2302 
Disk Storage Circuit Check plus Wrong Length Record) 
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No Transfer (Write Inhibit Switch on 7631 is Oi^l) 




Wrong Length Record(i.e., Incorrect Format Length, 
or No GM-WM at End of Disk Control Word) 
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Any indicator. (The group mark can only be 
specified as the second or sixth operand of the 
DTF ERRADDR entry.) 



Figure 57. Acceptable Characters 

If: (a) the channel status indicator(s) turned on by 
an error condition, or conditions, for the file exactly 
matches the channel status indicator(s) represented 
by the bcd code of one of the single-character oper- 
ands, and (b) two consecutive commas do not appear 
anywhere between the first operand and the single- 
character operand ( see the second and third operands 
in Figure 58), the iocs performs two operations. It 
bypasses its normal error procedures and causes the 
execution of a branch to the user's error routine. (If 
the first operand has been omitted, the iocs bypasses 
its normal error correction procedures, and accepts the 
record.) 

Note: This is the only type of exit that may be 
specified for files that refer to unit-record devices. 

If: (a) the channel status indicator (s) turned on by 
an error condition, or conditions, for the file exactly 
matches the channel status indicator(s) represented 
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Figure 58. erraddr Entry 

by the bcd code of one of the single-character oper- 
ands, and (b) two consecutive commas do appear 
somewhere between the first operand and that single- 
character operand ( see the fourth, fifth, and sixth oper- 
ands in Figure 58), the iocs causes the execution of a 
branch to the user's error routine only after the nor- 
mal IOCS error procedures have been executed, and 
the condition or conditions could not be corrected. ( If 
the first operand has been omitted, no branch is exe- 
cuted and the relevant operands become redundant.) 

Any single-character operand of this entry whose 
BCD code includes the B bit, cannot have its intended 
effect, if: (a) the file consists of Form 1 or Form 2 
data records, and (b) neither the wlr operand nor 
a fourth operand whose bcd code includes the B bit, 
has been specified in the dtf ekrcheck entry for the 
file. If the file: (a) consists of Form 3 or Form 4 data 
records, and (b) the wlr operand has been specified 
in the errcheck entry for the file, any single-char- 
acter operand of the dtf erraddr entry whose bcd 
code includes the B bit will have its intended effect, 
even though the bcd code of the fourth operand speci- 
fied in the errcheck entry for the file does not include 
the B bit. 

The second through sixth operands of the dtf 
erraddr entry are used to generate Field 14 of the 
relevant File Table. If two consecutive commas do 
not appear anywhere between the first operand and 
a single-character operand, the iocs uses a dcw to gen- 
erate that single character for inclusion in Field 14 of 
the relevant File Table. All single-character operands 
falling into this category will be generated for Field 14 
by Dcw's. If two consecutive commas do appear some- 
where between the first operand and a single-character 
operand, the iocs uses a dc to generate that single 
character for inclusion in Field 14. All single-charac- 
ter operands falling into this category will be gener- 
ated for Field 14 by dc's. The iocs utilizes Field 14 of 
the relevant File Table to determine for each error 
condition whether or not: (a) standard iocs error cor- 
rection procedures should be employed; (b) the iocs 
should exit to a user-written error routine; or (c) the 
IOCS should exit to a user-written error routine only if 
the standard error procedures fail to correct the error. 
Figure 59 illustrates the procedure taken by the iocs 
in determining the appropriate course of action. 
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Figure 59. iocs Determination of Error Correction Procedures 
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Disk IOCS Considerations: If ibm 1301 or 2302 Disk 
Storage has been specified at System Generation, and, 
consequently, an iocs with disk-handling capabilities 
is produced for the system, a group mark can be used 
as the second or sixth operand of the dtf erraddr entry. 
The following will apply to any file for which the dtf 
ERRADDR entry is made, regardless of the medium used 
for the file: 

1. If a group mark is entered in the position imme- 
diately following the first comma (i.e., as the second 
operand, and during processing any channel status 
indicator is turned on, the normal iocs error correction 
procedures will be bypassed. The iocs will branch to 
the user's error routine. Any operands present after 
the group mark are redundant. Figure 60 illustrates 
the use of the group mark as the second operand. 
(Note that the group mark immediately follows the 
comma after usererr.) 
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Figure (30. erraddr Entry ( Second Operand; ^ ) 

2. If a group mark is entered in the position. imme- 
diately following the sixth comma (i.e., as the sixth 
operand), and during processing a channel status in- 
dicator(s) is turned on, the normal iocs error pro- 
cedures will be bypassed only if a match occurs be- 
tween the channel status indicator configuration and 
any of the single-character operands preceding the first 
two consecutive commas. The sixth-operand group 
mark must by definition appear somewhere after two 
consecutive commas (see below). Therefore, if the 
channel status indicator combination does not match 
any of the single-character operands preceding the 
double comma, the iocs will, after encountering the 
group mark, attempt to correct the error; if this at- 
tempt fails, the program will branch to the user's error 
correction routine. Any single-character operand ( oth- 
er than the group mark) after the first pair of con- 
secutive commas is superfluous. Figure 61 illustrates 
the use of the group mark as the sixth operand. ( Note 
that a total of six commas precedes the group mark.) 

If the group mark appears as the sixth operand, and 
less than five single-character operands are included, 
a comma must be substituted for each missing oper- 
and (see Figure 62). Since the effect of the sixth- 
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Figure 62, erraddr Entry ( Operands Omitted ) 

operand group mark will not be i^alized unless it is 
preceded by a total of six commas (not necessarily 
consecutive), two consecutive commas must appear at 
some point. Therefore, any testing involving the group 
mark will result in an attempt by the iocs to correct 
the error before the branch to the user's error routine. 
In Figure 62, the first two commas entered before 
the group mark operand represent the omitted fourth 
and fifth operands. The third and fourth commas are 
the normal double-comma entry. 

LENGTH 

This entry is required if the file consists of Form 4 
data records and the programmer plans to use the 
PUT FILE, form4 macro-instruction to write on the file. 
The operand of the length entry is a label the iocs 
assigns to Field 12 of the File Table associated with 
the file. (This label must not be a linkage symbol. 
This label refers to the low-order position of the field.) 
Whenever the programmer is going to use the put 
file,form4 macro-instruction, he must first place, in 
this field, the estimated maximum length of the data 
record that is to be handled. The manner in which the 
iocs utilizes this information is discussed under put 
file,form4. An example of how this entry is coded is 
shown in Figure 63. ( See '"The Extended iocs Macro- 
Instructions" for a discussion of put file,form4 and 
"Internal Operation of the iocs" for a description of 
the File Table.) 
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Figure 61. erraddr Entry (Sixth Operand; ^) 



Figure 63. length Entry 
INTADDR 

This entry is not required. It is used to cause a branch 
to be taken to a service routine provided for the file 
by the programmer whenever execution of an input/ 
output operation (other than a Seek Disk operation) 
is completed on the file. 

The operand of the intaddr entry is the label of the 
user-written service routine provided for the file. 

If the dtf erraddr and. intaddr entries are both 
specified for the same file, the user's service routine is 
not entered if an input/output operation completed 
on the file results in an error condition, or conditions, 
that cause the iocs to exit to the error routine the 
programmer has provided for the file. 
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If the SKIP operand of the dtf erroptns entry and 
the iNTADDR entry are specified for the same file, the 
user's service routine is not entered if an input/output 
operation completed on the file results in an error 
condition, or conditions, that the iocs error procedures 
cannot correct. An example of how this entry is writ- 
ten is shown in Figure 64. (User-written service rou- 
tines are discussed under "User-Written Routines.") 
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Figure 64. intaddr Entry 



lineI 

This entry is not required. It is of significance only if 
the file is a tape file that uses labels. This entry allows 
the programmer to specify up to four exits to tape 
label routines the user has provided for the file. 

There are 16 exits (labeled A-H, J-N, P-R) available. 
These exits are in the iocs tape label routines. The 
position of each of these exits within the various iocs 
label routines is shown in Figure 65 (e.g., Exit A in 
the Input Reginning-of-Reel routine). The system 
symbols that identify the return points from these 
exits are also shown in Figure 65 (e.g., /lra/; the 
return point from Exit A.) 




Figure 65. iocs Tape Label Routines 
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The exits provided are taken depending on which 
reel of the file the relevant iocs label routine is 
processing. The characters R, F, or B indicate which 
reels of the file are to be affected, as follows: 

CHARACTER REELS AFFECTED 

R All reels of the file except the first, if the 

IOCS tape label routine in which the exit 
is to be taken is a beginning-of-reel routine. 
All reels of the file except the last if the 
aff^ected IOCS label routine is an end-of- 
reel routine. 

F Only the first reel of the file, if the affected 

IOCS label routine is a beginning-of-reel 
routine. Only the last reel, if the affected 
IOCS label routine is an end-of-reel routine. 

B AH reels of the file, regardless of the IOCS 

label routine in which the exit is to be 
taken. 

Each exit that is to be taken is coded as shown in 
Figure 66. 
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. Label of the user's routine 
.The character R, F, or B 
-The exit label (A-R) 



Figure 66. Coding Format for Exits to User- Written Label 
Routines (lineI) 



From one to four exits can be specified using this 
entry. The label lineI is entered in the proper field 
of the line of the coding sheet used for this entry and 
the relevant exits are specified on that same line. Each 
exit specified must be separated from the next by a 
comma. An example of how this entry is coded is 
shown in Figure 67. 

line2 

This entry cannot be used unless the lineI entry has 
been specified. Tliis entry allows the programmer to 
specify from one to four additional exits to user- 
written tape label routines. Each exit is coded as 
described under the lineI entry, and must be sepa- 
rated from the next (if any) by a comma. An example 
of how this entry is coded is shown in Figure 68. 

lineI above 

This entry is used to specify exits from the iocs tape 
label routines to tape label routines written for the file 
by the programmer when more than eight such exits 
are desired. This entry is not required. 
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Figure 68. line2 Entry 

The lineI above entry cannot be included if the 
lineI entry has been specified for the file. 

The desired exits are specified by providing coding 
of the format shown in Figure 69 for each exit. The 
exits and characters that can be included in this coding 
are the same as those discussed under the dtf lineI 
entry. 
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Figure 69. Coding Format for Exits to User- Written Label 
Routines (lineI above) 



Once the desired exits are specified, the relevant 
coding must be placed before the dtf Header Line 
entry for the file, as shown in Figure 70, and must be 
preceded by a single-character new like that shown on 
Line 1 of Figure 70. (This character can be any 
character except a special character such as $.) To 
complete the entry, the exact coding shown on Line 
13 of Figure 70 must be included among the dtf 
entries for the file. 

exten 

This entry is not required. It applies only to tape files 

that use labels which the iocs is to check. This entry 
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Figure 70. Placement of Coding for Additional Exits 
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can be used to label the File Table Extension gen- 
erated for the file by the dtf label entry. If the dtf 
LABEL entry has been omitted, the exten entry must 
be used to indicate which File Table Extension the 
IOCS is to reference while processing the labels of the 
file. (The File Table Extension is discussed under 
"Internal Operation of the iocs.") 

The operand of the exten entry is one of the fol- 
lowing: 

1. For files where the dtf label entry has been 
specified, it is the label assigned to the File Table 
Extension generated by the dtf label entry. 

2. For files where the dtf label entry has been 
omitted, it is the label that has been assigned to a 
File Table Extension the programmer generated, or 
a File Table Extension generated by the dtf label 
entry specified for another file. An example of how 
this entry is coded is shown in Figure 71. 
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Figure 71. exten Entry 

filelist 

This entry is used to associate iorw's the programmer 
has generated with a specific data file. The operand of 
the FILELIST entry is the low-order address of the 
Link Field of an iorw, or the first of a list of iorw's 
the programmer has created. 

The IOCS places this address in Field 5 of the ap- 
propriate File Table, if the dtf ioareas entry has not 
been specified for the file. If the dtf ioareas entry has 
been specified, the iocs places this address in the Link 
Field of the last iorw on the File List associated with 
the file. (File Tables and File Lists are discussed under 
"Internal Operation of the iocs.") An example of how 
this entry is coded is shown in Figure 72. 

If the filelist entry is used, the iocs assumes that 
the file uses two or more input/output areas. For this 
reason, if any macro-instructions except get file to 

WORK, PUT WORK TO FILE, Or PUT WORK TO FILE, d are 

issued against the file, the dtf index entry must also 
be included in the dtf statement written for the file. 



Figure 72. filelist Entry 

User-WriHen Routines 

Five types of user-written routines can be included 
in programs that incorporate the iocs. The five types 
are end-of-file, error, service, scramble, and label 
routines. End-of-file, error, service and label routines 
are discussed here. Scramble routines are discussed 
under "Disk File Processing." 

Note: The iocs does not store or alter the status 
of the arithmetic overflow or divide overflow indicators 
before entering user-written routines. 

USER- WRITTEN SERVICE ROUTINES 

The lOCTL ENTRY macro-instructiou must be the first 
instruction of every user-written service routine. The 
second operand of this macro-instruction must be the 
label entered as the operand of the dtf intaddr entry 
specified for the file. The label that appears as the sec- 
ond operand of this macro-instruction refers to the 
low-order position of the coding (see Figure 73) de- 
veloped by the macro-instruction. This coding im- 
mediately precedes the user-written routine. For this 
reason, the first instruction of this routine can be re- 
ferred to by this label +1. 

The lOCTL EXIT macro-instruction must be the last 
instruction of every user-written service routine. ( The 
lOCTL ENTRY and locTL EXIT macro-instructions are 
discussed under "Extended iocs Macro-Instructions.") 

User-written service routines must not issue a get 
or PUT macro-instruction that results in detection of an 
end-of-reel or end-of-file condition. User-written service 
routines must not issue ioctl open, close, relse, 
CHKPT, or FEOR at a time when the iocs may be pro- 
cessing an lOCTL OPEN, CLOSE, RELSE, or FEOR cncouut- 
ered in the user's main-line program, unless a Tele- 
processing device has been specified for the using in- 
stallation at System Generation by means of the devdf 
macro-instruction. (See the System Generation pub- 
lication.) 



Line. 



fiii 



SLJL. 
^^ 

0,9. 
0.». 
O.T. 

o.e. 



Label 



Senvcx 



Operation 
- 2fi 



pCHf Qb.t.h.b.LSi . . . X f-Pt".'^. <•'>< ■€?*.'-J?). ■ ■ 



»0.J> 



\B.L. 



OCTL 



ENTRY. SeRYCLBL . 



DCW. 



-U 



IS- 



_4fl_ 



OPERAND 
_4fl BJL 



JUL 



_fta- 



-IL. 



-Zfi. 



DCM^ . S>tt.bki.i<3>. 



h^,H< , «fi^ifH.k.i.k.ke> X^'-hi'-Jfi'^l 



&i>.k.i.b.bS) . . ■ xp^i. p^fsy 






■ ■ ■ ■ ' I I i_i i_j 1—1—1 1 I J I 



1 i L 



_L_J I I- 







Figure 73. Coding Developed by ioctl Entry 
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User-written service routines cannot issue a get or 
PUT against the file with which they are associated, 
unless at least one iorw is on the File List of the file 
at the time the macro-instruction is issued. User- 
written service routines cannot issue a get or put 
against a file other than the one with which they are 
associated if the dtf intaddr entry has been specified 
for the aflFected file, unless there is at least one iorw 
on the File List of the afiFected file at the time the get 
or put is issued. In a tp environment, service routines 
should not use index registers for communication be- 
tween themselves and other service routines, or them- 
selves and the main line. 

user- written label routines 

The IOCS reads tape labels into and writes tape labels 
out of the areas shown in Figure 74. These areas are 
referred to by the system symbols indicated. 

120-Chqrocter L9bel Read/Write Area 



80-Character Read/Write Area 



/LLA/ /SLA/ 

Figure 74. Tape Label Read/Write Areas 

Except for ioctl open, <xose, relse, chkpt, and 
FEOR, user-written label routines can utilize all the 
IOCS macro-instructions, provided their use does not 
result in an end-of-reel or end-of-file condition (i.e., a 
get that causes the final tape mark to be sensed, or a 
PUT that causes the final reflective strip to be sensed). 

Generalized user-written label routines that process 
the. labels of more than one file can obtain the address 
of the File Table of the aflEected file from index reg- 
ister 13, or from a five-digit field whose low-order 
address is referred to by the system symbol /lfa/. 
(ab zone bits appear over the units position of both 
index register 13 and the five-position field.) 

Before returning to the Input End-of-Reel routine be- 
yond Exit E ( see Figure 65), user-written label routines 
designed to process nonstandard input trailer labels 
may place either "R" or "F" in a location referred to by 
the system symbol /lef/. The character should be R 
if the programmer wishes the iocs to process the next 
reel of the file; the character should be F if no addi- 
tional reels of the file are to be processed. 

Note: As the branch to user- written label routines is 
via a bepa instruction, a branch back to iocs should 
be via a bxpa instruction. 

USER- written ERROR ROUTINES 

At the time a branch is executed to a user-written 
error routine, the following information is available to 
the programmer: 

1. Index register 13 contains the address of the low- 
order position of Field 5 of the aflFected File Table. 



(ab zone bits appear over the units position of X13.) 
However, the contents of X13 are destroyed if any iocs 
macro-instruction is issued within the routine or a 
branch instruction is executed to the Resident Mon- 
itor. The user must not clear X13 to blanks. 

2. Field 10 of the aflFected File Table contains the 
address of the re-entry point into the calling sequence 
generated by the get or put macro-instruction, the 
execution of which uncovered the relevant error con- 
dition. 

3. The aflFected iorw is at the top of the File List 
with which it is associated. 

4. The Channel Status Character in the aflFected 
IORW indicates the channel status indicators that were 
turned on by the relevant error condition. 

Once a branch has been executed to a user-written 
error routine, that routine can cause the erroneous 
record: (a) to be processed as if it were error free, 

(b) to be overlaid, if the file is an input file, by 
reading the next physical record from the aflFected file 
into the input area that contains the erroneous record, 

(c) to be backspaced over, if the file is a tape file, 
and reread into or rewritten out of current input/out- 
put area of the aflFected file, or (d) to be written on 
the system's Core Image file or on another file set up by 
the programmer for this purpose. 

If the erroneous record is to be processed as if it 
were free of error, the user-written error routine must 
cause a branch to be executed to the address contained 
in Field 10 of the aflFected File Table. 

If the next physical record is to be read into the same 
area that contains the erroneous record, the user's 
routine must change the B bit in the second File 
Indicator (F2) of the aflFected File Table to an A bit 
by executing the instruction mrzr *, filename-I-12, and 
cause a branch to be taken to the address in Field 10 
of the aflFected File Table. 

If the erroneous record is a tape record and is to be 
reread or rewritten, a unctl file,bsp macro-instruc- 
tion must be issued against the relevant file, the block 
counter (Field 2) in the aflFected File Table must be 
decremented by one, and the steps outlined in the 
preceding paragraph must be executed. If the errone- 
ous record is a sequential disk record, the disk ad- 
dress in Field 2 or 3 of the appropriate File Table 
must be decremented, and the steps outlined in the 
preceding paragraph executed. 

If the erroneous record is to be written on the Core 
Image file, the programmer must have coded a dtf 
statement for that file, included mdm as the second op- 
erand of the relevant dtf symunit entry, included the 
DTF MODE entry with its odd operand, and opened the 
file by means of the ioctl open,output macro-instruc- 
tion. The user's routine must then place the B-address 
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of the input/output operation that appears in the 
aflfected iorw in the iorw associated with the Core 
Image file, and issue a put macro-instruction against 
the Core Image file. 

This action causes the erroneous record to be written 
on the Core Image file. The erroneous record may 
then be processed or overlaid as described in the 
preceding paragraphs. 

If the erroneous record is to be written on a file set 
up by the programmer for this purpose, the procedures 
outlined for writing the erroneous record on the Core 
Image file must be followed, with one exception. The 
second operand of the relevant dtf symunit entry 
cannot be mdm. 

Note 1: If a file consists of Form 4 records and the 
error routine provided for the file determines that a 
block of records on which an error condition exists is 
to be processed as if it were error free, the program- 
mer must make sure that the Record Character-Count 
in each record of the block is accurate. 

Note 2: User error routines provided for an output 
file cannot issue ioctl open, close, feor, or relse. 

USER- written END-OF-FILE ROUTINES 

Once the end-of-file routine provided for a file has 
been entered, no further get or put macro-instructions 
can be issued against the afiFected file, unless the file 
is closed and then reopened. The work files discussed 
in Appendix E are an example of the type of files on 
which this situation might frequently occur. 

When an end-of-file condition occurs on a disk out- 
put file, the IOCS removes all iorw's associated with 
the file from the Read/Write List and places them on 
the bottom of the File List associated with the file. 
The iocs next causes a branch to be taken to the end- 
of-file routine the user has provided for the file. The 
programmer cannot then use the ioctl close, output 
macro-instruction to write on the file any data re- 
maining in the output areas associated with the file. 
The reasons for this are: (a) the file cannot accept 
any additional data, and (b) the iorw's that refer to 
the relevant output areas are on the File List of the 
file. The programmer must himself determine where 
and how any data contained in these output areas is 
to be disposed of. 

Extended IOCS Macro-Instructions 

The extended iocs macro-instructions are listed below, 
and discussed in the paragraphs that follow. 



IOCTL TYPE,AREA,DEFER 
UNCTL FILE,CC,d 
UNCTL FILE,SSF,d 
UNCTL FILE,BSP 



UNCTL FILE,RWD 
UNCTL FILE,RWU 
UNCTL FILE,WTM 



GET FILE,DEFER 
PUT FILE, DEFER 
PUT FILE,FORM4 
PUT FILE,d 
PUT WORK TO FILE,d 
PUT FILE TO FILE,d 



IOCTL RELSE,(I/0),FILE 
IOCTL FEOR,(I/0),FILE 
IOCTL ENTRY 
IOCTL EXIT 
IOCTL CHKPT 
IOCTL TYPE,AREA 



GET FILE,DEFER 

This macro-instruction is designed for use with input 
files that consist of unblocked records and use a single 
input area. It allows the programmer to overlap read 
operations and processing when only one input area 
has been assigned to the file. This macro-instruction 
causes the iocs to schedule execution of an input 
operation that is to read a record from the indicated 
file, (e.g., the file labeled infile in Figure 75) into 
the input area specified for the file. This macro- 
instruction then causes the iocs to branch to the next 
sequential instruction of the using program without 
waiting for execution of the requested input operation 
and subsequent release of the input area to the using 
program (i.e., the iocs defers making the requested 
record available in the input area of the file.) 

Once GET file,defer has been issued, the using pro- 
gram can process any data except data contained in 
the input area. When the program has completed 
whatever processing is required, get file, get file to 
WORK, or GET FILE TO FILE can be issued. These macro- 
instructions cause the iocs to make the record read 
as a result of issuing get file,defer available to the 
user's program. 

If the programmer wishes, instead of get file, get 
FILE TO WORK, or GET FILE TO FILE, the character in 
Field Q4 of the aflfected iorw can be tested to deter- 
mine if the relevant input area is available. If the bcd 
code of the character in Field Q4 includes the A bit, 
the requested input operation has been completed and 
the associated area is available. If the programmer 
substitutes a B bit for the A bit, he may access the 
contents of the input area. If the bcd code includes the 
B bit, the requested operation has not been completed 
and the programmer can: (a) process other data, 
(b) wait until the iocs replaces the B bit with an A 
bit, or (c) issue one of the get macro-instructions 
noted above, to eflfect completion of the operation. 

Note: When the user makes the input area avail- 
able in this manner, he must make provisions for ex- 
ception processing (i.e., error or end of file) himself, 
and ensure that A bits are present in F5, Q5, and Q6 
before normal processing can continue. 

If GET FiLE,DEFER is uscd, the IOCS suppresscs the 
check for end of file that the other get macro-instruc- 
tions cause it to make. However, the use of get file, 

GET FILE TO WORK, Or GET FILE TO FILE, SubscqUCnt tO 

the use of get file,defer causes the iocs to recognize 
an end-of-file condition that results from the issuance 
of GET file,defer. An example of how this macro- 
instruction is coded is shown in Figure 75. 
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Figure 75. get file,defer 
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Figure 76. put file,defer 



PUT riLE,DEFER 

This macro-instruction is designed for output files that 
consist of unblocked records and use a single output 
area. It allows the programmer to overlap write op- 
erations and processing when only one output area 
has been assigned to the file, put file,defer causes 
the IOCS to schedule execution of an output operation 
that is to write, on the a£Fected file (e.g., the file 
labeled outfile in Figure 76), a record taken from 
the output area specified for the file. This macro- 
instruction then causes the iocs to branch to the next 
sequential instruction of the user's program, without 
waiting for actual execution of the requested write 
operation and release of the output area to the pro- 
gram (i.e., the iocs defers making the output area 
available to the using program). 

Once PUT FiLE,DEFER has been issued, the using pro- 
gram can process any data except that data contained 
in the output area of the file. When the program has 
finished processing the relevant data, put file can be 
issued. This macro-instruction causes the iocs to en- 
sure that the write operation scheduled by put 
file,defer has been executed. The iocs then makes 
the output area of the file available to the program. 

If the programmer wishes, instead of issuing put 
FILE the character in Field Q4 of the aflFected iorw 
can be tested to determine if the relevant output area 
is available. If the bcd code of the character in Field 
Q4 includes the A bit, the requested write operation 
has been executed, and the output area associated 
with the file is available to the using program. If the 
programmer substitutes a B bit for the A bit, he may 
access the output area. 

If the BCD code of the character includes the B bit, 
the requested operation has not been completed and 
the programmer can: (a) process other data, (b) wait 
until the iocs replaces the B bit with an A bit, or 
(c) issue a put macro-instruction against the file to 
eflFect the completion of the requested write operation. 

If PUT FiLE,DEFER is uscd, the IOCS supprcsscs the 
check for end of file which other put macro-instruc- 
tions cause it to make. However, the subsequent use 

of PUT FILE, PUT WORK TO FILE, Or PUT FILE TO FILE 

causes any end-of-file condition that resulted from use 
of PUT FiLE,DEFER to be recoguizcd by the iocs. An 
example of the way in which thi§ put macro-instruc- 
tion is coded is shown in Figure 76. 



PUT file,form4 

This macro-instruction is only used when the affected 
file (e.g., the file labeled outfile in Figure 77) con- 
sists of Form 4 records and the programmer plans to 
move the next logical record into the current output 
area of that file by means of a move instruction, rather 
than by means of an iocs macro-instruction. 

PUT file,form4 is used as follows: 

1. The programmer places the actual length, or the 
maximum possible length, of the record that is to be 
moved in a five-digit field whose label is the operand 
of the dtf length entry specified for the file. This 
placement should be accomplished by means of a 
Zero and Add instruction ( za). 

2. The programmer issues put file,form4. This 
macro-instruction causes the iocs to check the current 
output area of the file. (In performing this check, the 
IOCS destroys the contents of the five-digit field that 
is referred to by the label entered as the operand of 
the length entry.) An example of how this put file, 
form4 macro-instruction is coded is shown in Figure 
77. 

If the current area does not contain enough positions 
unoccupied by data to absorb the record, the current 
contents of the area are written on the file and the 
IOCS branches to the next sequential instruction of the 
program. 
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Figure 77. put file,form4 

If the current area contains enough positions to 
absorb the record, the iocs branches to the next se- 
quential instruction of the program. 

3. The programmer moves the next logical record 
into the current output area by means of a move 
instruction that wipes out any extraneous word marks 
in that portion of the current output area that is taken 
up by the next logical record. 

4. The programmer issues put file. This macro- 
instruction causes the iocs to account for the record 
the programmer moved into the output area and to 
branch to the next sequential instruction of the pro- 
gram. 
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PUT FILE,d PUT WORK TO FILE,d PUT FILE TO FILE,d 

These macro-instructions may only be used with 
punched card or printer files. They perform, respec- 
tively, the same functions as put file, put work to 
FILE and PUT file to file. 

In addition, these macro-instructions : 

1. For punch files, allow the programmer to alter 
the stacker assigned to the file during execution of 
the user's program. (This is accomplished by substi- 
tuting 0, 4, or 8 for the d-character shown in Figure 
78.) 

2. For printer files, allow the programmer to specify, 
during execution of the program, whether the Write 
A Line or the Write Word Marks instruction is to be 
used to write on the file. This is accomplished by sub- 
stituting (i.e.. Write A Line) or 1 (i.e., Write Word 
Marks) for the d-chafacter shown in Figure 78. 

The last put FiLE,d, put work to FiLE,d, or put 
file to FiLE,d encountered during execution of the 
using program establishes the stacker or print instruc- 
tion that is to be used for the balance of the program, 
provided the file uses a single output area. If the file 
uses multiple output areas, the programmer must is- 
sue PUT FILE,d, PUT work TO FILE,d, Or PUT FILE TO 

FiLE,d for the balance of the program whenever he 
issues a put macro-instruction against the aflfected file. 
If none of these macro-instructions are used in the 
program, the stacker or instruction specified in the 
DTF order entry for the file is the stacker or instruc- 
tion used throughout the program. An example of how 
these macro-instructions are coded is shown in Figure 
78. 
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Figure 78. put FiLE,d; put work to FiLE,d; and put file to 

FILE,d 



lOCTL RELSE, ( INPUT/oUTPUT ) ,FILE 

This macro-instruction may only be used with files 
that consist of Form 2 or Form 4 data records. This 
macro-instruction causes the iocs to make the current 
block of data records from the relevant file unavailable 
to the user's program. The first operand of this macro- 
instruction is RELSE (Release), the second operand is 
INPUT (for input files), or output (for output files); 
the third operand is the name of the affected file. 

If the second operand is input, the iocs ignores 
any records in the current input area that have not 
been made available to the program, and the next 
GET macro-instruction issued against the file causes 



the IOCS to make the first record of the next logical 
block of records available to the program. 

If the second operand of this macro-instruction is 
OUTPUT, the IOCS: (a) ignores the fact that the block 
of records in the current output area of the file is in- 
complete, (b) pads the incomplete block if the file 
consists of Form 2 records, and (c) schedules the 
writing of the block on the appropriate file. The next 
logical record moved into the output area then be- 
comes the first record of a new block. An example of 
how this macro-instruction is written is shown in Fig- 
ure 79. 
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Figure 79. ioctl relse, ( input/output ) ,file 
lOCTL FEOR,( input/output), FILE 

This macro-instruction is issued against tape files to 
force an end-of-reel condition. The first operand of this 
macro-instruction is feor (Force End of Reel). The 
second operand is input (for input files) or output 
(for output files). The third operand is the label of 
the affected file. 

If the second operand is input, a branch is im- 
mediately taken to the iocs Input End-of-Reel rou- 
tine. As a result, the trailer label of the affected reel 
is not processed, and no check is made to determine 
if an end-of-file condition exists on the file. 

If the second operand of this macro-instruction is 
output, the IOCS: (a) completes all output operations 
issued against the file that are still pending, (b) pads 
the last block of data records if the file consists of 
Form 2 records and the last block is incomplete, (c) 
writes on the file all records (or blocks of records) 
in the output area(s) of the file, and (d) branches to 
the appropriate iocs Output End-of-Reel routine. An 
example of how this macro-instruction is written is 
shown in Figure 80. 

lOCTL entry, (label OF SERVICE ROUTINE) 

The IOCTL ENTRY macro-instructiou must be the first 
instruction of every user-written service routine. It 
is used to define the entry point into the user-written 
service routine whose label appears as its second oper- 
and. Figure 81 shows an example of how this macro- 
instruction is written. (The coding generated by this 
macro-instruction is shown in Figure 73.) 
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Figure 80. ioctl feor, ( input/output ) ,file 
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Figure 81. ioctl b;ntry 

lOCTL EXIT,ACCEPT IOCTL EXIT,DELETE 

One of these macro-instructions must appear as the 
last instruction of every user-written service routine 
(see Figures 82 and 83). ioctl exit,accept causes the 
IOCS to accept the results of the input/output opera- 
tion, the completion of which initiated entry into the 
affected user-wiitten service routine, ioctl exit,delete 
causes the iocs to note that the iorw associated with 
the input/output operation, the completion of which 
initiated entry into the affected user-written routine, 
has been deleted from the group of iorw's (i.e., the 
Service List) associated with the routine. The iocs 
assumes the user has disposed of the iorw. (Service 
Lists are described under "Internal Operation of the 

IOCS.") 
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Figure 83. ioctl exit,delete 
IOCTL CHKPT 

This macro-instruction causes the iocs to write three 
records on the Core Image file. The first of these 
records includes the entire contents of core storage. 
The second includes the contents of core storage from 
the last position occupied by the Resident Monitor +1 
to the end of core storage. The third includes the 
contents of core storage from the address specified as 
the tenth operand of the iokdf macro-instruction to 
the end of core storage. (See the System Generation 
publication.) This address is automatically stored in 
a five-position field whose low-order position may be 
referred to by the system symbol /ogr/. 

Once this macro-instruction has been executed a 
message is written on the console printer notifying the 
operator that a checkpoint is being taken. 

The use of this macro-in,struction allows the program 
to be restarted at the point in the program where the 
IOCTL CHKPT macro-instruction was issued. For a de- 
scription of the procedure for restarting programs 



from a checkpoint see the publication, IBM 1410/7010 
Operating System; Operators Guide, Form C28-0351. 
Programs that use the ioctl chkpt macro-instruc- 
tion must observe the following conventions: 

1. Each time a tape is backspaced by means of the 
UNCTL FiLE,BSP macro-iustructiou, the block counter 
(Field 2 of the File Table) of the affected file must 
be decremented by one. 

2. If any reel of a tape file has been rewound by 
means of the unctlfile,rwd or unctlfile,rwu macro- 
instruction since the last time the file was opened, 
that file must be closed before the ioctl chkpt macro- 
instruction is executed if the file uses labels. If the file 
does not use labels, it need not be closed, but Field 2 
of the relevant File Table must be zeroed before the 
macro-instruction is executed. 

3. The ioctl chkpt macro-instruction cannot be 
used if a file is open for which N has been specified 
in the operand field of the dtf rwdoptns entry, and 
the condition specified by the operand field in which 
it appears (e.g., beginning of reel, end of reel, etc.) 
has occurred. 

4. If two or more files use the same tape unit, only 
one of these files can be open at the time the ioctl 
CHKPT macro-instruction is executed. 

5. If one or more iorw's have been added to the 
File List associated with a tape file after the file is 
opened, and the new iorw's reference a different tape 
unit than the iorw's that were on the File List at the 
time the file was opened, the file must be closed be- 
fore the IOCTL CHKPT macro-instruction is executed. 

If the iorw's on the File List of a tape file have been 
altered, since the file was opened, to reference a tape 
unit other than the unit they were assigned to at the 
time the file was opened, the affected file must be 
closed before the ioctl chkpt macro-instruction is 
executed. 

6. Files which use 1410 80-character or ibm Stand- 
ard 120-Character labels cannot be open at the time 
the ioctl chkpt macro-instruction is executed if the 
File Table Extension address or the contents of the 
File Table Extension used by the files have been mod- 
ified since the file was opened. 

7. Any file that uses nonstandard labels cannot be 
open at the time the ioctl chkpt macro-instruction is 
executed, if the exits provided in the iocs tape label 
routines are used by the programmer to bypass iocs 
reading or writing of the labels used by the file. 

8. Word separator characters with word marks can- 
not be present in that area of core storage occupied by 
the using program at the time the ioctl chkpt macro- 
instruction is executed. 

9. Checkpoints cannot be taken at a point in the 
user's program that will require the restart program 
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to position a reel of tape at a record that is longer 
than the algebraic diflFerence between the integers at 
/ogr/ and /org/ if any 7330 magnetic tape drives are 
on that channel. 

10. Checkpoints cannot be taken in any service rou- 
tine that might interrupt the tape open, close, feor, 
or EOR routine. 

11. Checkpoints cannot be taken in any label exit 
routines. 

12. Checkpoints cannot be taken if the algebraic 
difference of the integers at */ogr/ and /org/ is less 
than the value of the integer at /org/. (The value at 
/org/ is the size of Resident Monitor.) 

If the system is reinitialized and no assignment is 
made for the Core Image file, a subsequent request for 
a checkpoint will result in the following: (a) the check- 
point routine will be entered and (b) functions such as 
the incrementing of the checkpoint count will be per- 
formed. However, the write operations will be bypassed. 

After an ioctl chkpt macro-instruction has been 
executed, a four-position field (whose units positions 
can be referred to by the system symbol /cpt/) con- 
tains the serial number (thousands, hundreds, and 
tens positions of the field) of the checkpoint that was 
just written. The units position of this field contains 
an indicator that the using program can interrogate 
to determine if the program has been restarted from 
the last checkpoint taken. This indicator is the char- 
acter R if the program has been restarted. In this case, 
the thousands, hundreds, and tens positions indicate 
the serial number of the checkpoint from which the 
program was restarted. An example of how this entry 
is coded is shown in Figure 84. 
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Figure 84. ioctl chkpt 
IOCTL TYPE,AREA 

This macro-instruction is used to cause the iocs to 
write the contents of a specified area of core storage 
on the console printer. This action is taken before the 
next sequential instruction of the using program is 
executed. The first operand of this macro-instruction is 
TYPE. The second operand is any label that refers to 
the high-order position of the area whose contents are 
to be written on the console printer. The second op- 
erand must not be indexed. A group mark with word 
mark must appear immediately to the right of the 
low-order position of this area. Figure 85 shows an 
example of how this macro-instruction is coded. 



Figure 85. ioctl type,area 
IOCTL TYPE,AREA,DEFER 

This macro-instruction causes the iocs to schedule the 
writing of the contents of a specified area of core stor- 
age on the console printer. The iocs then executes the 
next sequential instruction of the using program with- 
out waiting for execution of the scheduled write oper- 
ation. The first operand of this macro-instruction is 
TYPE. The second operand is any label that refers to 
the high-order position of the area whose contents are 
to be written on the console printer. The second op- 
erand must not be indexed. A group mark with word 
mark must appear immediately to the right of the 
low-order position of this area. The third operand is 
DEFER. An example of how this macro-instruction is 
written is shown in Figure 86. 
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Figure 86. ioctl type,area,defer 

UNCTL Macro-Instructions 

There are six unctl macro-instructions. They may be 
used to generate the coding required to perform cer- 
tain control functions on the input/output unit as- 
signed to a file. These macro-instructions are discussed 
in the paragraphs that follow. The control functions 
they perform are discussed in detail in the publications 
IBM 1410 Principles of Operation, Form A22-0526, and 
IBM 7010 Principles of Operation, Form A22-6726. 

Note 1: The first operand of every unctl macro- 
instruction is the name of the affected file. The pro- 
grammer may substitute for the name of the file, the 
system symbol entered as the second operand of the 
DTF SYMUNiT entry specified for the file. If this substitu- 
tion is made, the relevant system symbol must be pre- 
ceded and followed by a slash (e.g., /mr9/). (When 
this symbol is entered in the dtf symunit entry, it may 
or may not be preceded and followed by slashes.) 

Note 2: Control functions are immediately per- 
formed on the appropriate input/output device with- 
out consideration of any pending operations for that 
device. Therefore, it may be necessary for the user to 
ensure that all such pending operations are completed 
before a unctl macro-instruction is issued, unless only 
one area is defined for the file and the defer forms of 
the GET or PUT macro-instruction are not used. The 
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following is an example of the coding that could be 
used to ensure completion of all pending operations 
for a two-area file. 

BACK ZA FILENAME,X13 

BZ BACK 

ZA 0+xl3,xl3 

BZ BACK 

If additional areas are defined for the file, the last 
two instructions must be repeated for each additional 
area. 

UNCTL FILE,CC,d 

This macro-instruction (see Figure 87) corresponds to 
the cc (Control Carriage) mnemonic instruction for 
the 1403 Printer. The first operand is the label of the 
file to which the printer is assigned. The second oper- 
and is cc. The third operand is the d-character of the 
Control Carriage instruction. 
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Figure 87. uncti. FiLE,cc,d 
UNCTL FILE, SSF,d 

This macro-instruction (see Figure 88) corresponds to 
the ssF (Select Stacker and Feed) mnemonic instruc- 
tion for the 1402 Card Read Punch. The first operand 
is the name of the file to which the card reader is as- 
signed; the second operand is ssf; the third operand 
is the d-character of the Select Stacker and Feed in- 
struction. (If this macro- instruction is used, the dtf 
statement for the aflFected file must include the dtf 
ORDER entry with 9 as its operand.) 
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Figure 88. tnsrcTL FiLE,ssF,d 
UNCTL FILEjBSP 

This macro-instruction (Figure 89) corresponds to the 
Bsp (Backspace) mnemonic instruction for ibm mag- 
netic tape units. The first operand is the name of the 
file to which the tape unit is assigned. The second op- 
erand is the Backspace mnemonic instruction. 
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Figure 89. unctl file,bsp 



UNCTL FILE,RWD 

This macro-instruction (Figure 90) corresponds to the 
RWD (Rewind) mnemonic instruction for ibm mag- 
netic tape units. The first operand is the name of the 
file to which the tape unit is assigned. The second op- 
erand is the Rewind mnemonic instruction. 
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Figure 90. unctl file,rwd 
UNCTL FILE,RWU 

This macro-instruction (Figure 91) corresponds to the 
Rwu (Rewind and Unload) mnemonic instruction for 
IBM magnetic tape units. The first operand is the name 
of the file to which the tape unit is assigned. The sec- 
ond operand is the Rewind and Unload mnemonic in- 
struction. 
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Figure 91. unctl file,rwu 
UNCTL FILE,WTM 

This macro-instruction (Figure 92) corresponds to the 
WTM (Write Tape Mark) mnemonic instruction for 
IBM magnetic tape units. The first operand is the name 
of the file to which the unit is assigned. The second 
operand is the Write Tape Mark mnemonic instruction. 
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Disk File Processing 

This section provides information for using the iocs 
to process disk files in bm 1301 or 2302 Disk Storage. 
The IOCS can be used in processing data files in ibm 
1301, 2302, or 1311 Disk Storage, although ibm 1311 
Disk Storage Units cannot share a channel with ibm 
1301 or 2302 Disk Storage Units, iocs information pe- 
culiar to handling disk files residing in ibm 1311 Disk 
Storage can be found in the publication Support of 
IBM 1311 Disk Storage Drives Under the Operating 
System. The 1311 publication refers to portions of the 
following information that are also applicable to the 
1311. 



Extended Use of the IOCS 37 



Disk Files 

A disk file is a data file residing on a disk storage unit. 
The IOCS can read and write ibm 1301, 2302, and 1311 
disk files. If a disk file is to be read from or written on 
the 1301 or 2302, the first operand of the dtf symunit 
entry must be 1301 or 2302, and the operand of the 
DTF ORDER entry must specify the disk input/output 
instruction that is to be used to process the file. 

Programs that incorporate the iocs may only read 
from or write on those disk files contained in modules 
of 1301 or 2302 Disk Storage that have been specified, 
at System Generation, by means of the dskdf macro- 
instruction. 

The SKIP operand of the dtf erroptns entry may not 
be specified for any nonsequential disk file. The dtf 
EOFADDR entry must be specified for all sequential disk 
files. If multiple i/o areas are utilized for processing 
a nonsequential disk file, the user must initialize all the 
areas before issuing the first get macro-instruction. 

Note: The operand of the DTF FILEFORM entry 
for nonsequential disk files must be 1 or 3. The operand 
of the lO AREAS entry refers to the high-order position 
of the Track Address or Track/Record Address field. 

The various types of sequential and nonsequential 
disk files are discussed in the following sections. 

FORMA 

A Form A (Sequential-Full Track) disk file is a disk file 
organized in such a way that: (a) it is to be read or 
written by means of the Read/Write Full Track With- 
out Record Addresses, the Read/Write Full Track 
With Home Address, or the Read/Write Full Track 
With Addresses instruction, and (b) the iocs is to in- 
crement the current track address by one to obtain the 
address of the next track to be read or written. 

When the current track address of a Form A disk 
file has been incremented to the point where it is one 
higher than the address of the last track contained in 
the current physical unit assigned to the file, the iocs 
determines: (a) whether an alternate physical unit is 
to be assigned to the file, or (b) whether an end-of-file 
condition exists on the file. If an alternate unit is to be 
assigned, the iocs links with the System Monitor to 
effect the assignment and then passes control to the 
user's program. If an end-of-file condition exists on the 
file, the iocs causes a branch to be executed to the 
user's end-of-file routine for the file. 

Input/output areas associated with Form A disk files 
must conform to the format shown in Figure 93; the 
DA statements used to define these areas are shown in 
Figure 94. 

The IOCS supplies the information contained in the 
Track Address Field shown in Figure 93. The iocs up- 
dates the current track address at the low-order posi- 
tion of the subfield shown at tttt. 
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Figure 94. da Statements for Form A,B,C,D, and G Disk Files 
FORMB 

A Form B (Nonsequential-Full Track/Cylinder) disk 
file is a disk file organized in such a way that: (a) it is 
to be read or written by means of one of the Full 
Track instructions or by means of the Read/Write 
CyHnder Operation instruction, and (b) the iocs can- 
not increment the current track address by one to 
obtain the address of the next track that is to be read 
or written. 

Note: Form B disk files are the only disk files that 
may be read or written by means of the Read/Write 
Cylinder Operation instruction. 

For Form B disk files, the iocs makes no check to 
determine if an end-of-physical-unit or end-of-file con- 
dition has occurred on the file. 

Input/output areas associated with Form B disk files 
must conform to the format shown in Figure 93. The 
DA statements used to define these areas are shown 
in Figure 94. 

For this type of disk file, the programmer must sup- 
ply the information contained in the Track Address 
Field. 

To read records from or write records on Form B 
disk files, the programmer must perform the following 
operations : 

1. Place the address of the next disk track the iocs 
is to read or write in the appropriate portion of the 
Track Address Field associated with the input/output 
area that is to handle the affected records. 

2. Make sure that the B-address of the input/out- 
put instruction in the iorw at the top of the File List 
associated with the affected file refers to the appropri- 
ate input/output area. 

3. Issue the nonsequential form of the desired get 
or PUT macro-instruction. (See "Disk Macro-Instruc- 
tions.") lORw's, File Lists, and File Tables are dis- 
cussed under "Internal Operation of the iocs." 
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Single-Record Disk Files 

A single-record disk file is a disk file the iocs is to read 
or vmte by means of the Read/Write Single Record 
instruction. There are five types of single-record disk 
files. Each of these five types is discussed in the ma- 
terial that follows. 

FORMC 

A Form C (Sequential-Geometric) disk file is a single- 
record disk file organized in such a way that: (a) the 
IOCS can increment the current record address by one 
to obtain the address of the next record that is to be 
read or written, (b) the first four digits of the address 
of each record of the file are identical to the first four 
digits of the address of the disk track on which the 
record resides, (c) each track of the file contains the 
same number of data records, and (d) the two low- 
order digits of the first record address on each track 
are 00. 

The DTF FiLEFORM entry for this type of file must in- 
clude a second operand. This second operand is an in- 
teger equal to the number of data records contained 
on any one track of the file. An example of a fileform 
entry that includes this operand is shown in Figure 95. 
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Figure 95. filee'orm Entry (Second Operand Included) 

Input/output areas associated with Form C disk files 
must conform to the format shown in Figure 96. The 
DA statements used to define these areas are shown in 
Figure 94. 

The iocs supplies the information contained in the 
Track/Record Address Field shown in Figure 96. 

When the number of data records read from or 
written on a disk track of this type of file equals the 
integer specified as the second operand of the dtf 
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FILEFORM entry for the file, the iocs: resets the subfield 
YY shown in Figure 96 to zeros ((X)), and increments 
the subfield xxxx by one. 

If the current track address of a Form C disk file 
has been incremented to the point where it is one 
higher than the last track of the current physical unit 
of the file, the iocs performs the same functions de- 
scribed under "Form A." 
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A Form D (Nonsequential-Geometric) disk file is a 
single-record disk file organized in such a way that: 
(a) the iocs cannot increment the current record ad- 
dress by one to obtain the address of the next record 
to be read or written, and (b) the first four digits of 
the address of each record contained in the file are 
identical to the first four digits of the address of the 
disk track on which the record resides. 

Input/output areas associated with Form D disk 
files must conform to the format shown in Figure 96. 
The DA statements used to define these areas are 
shown in Figure 94. 

The programmer must supply the information shown 
in the Track/Record Address Field illustrated in 
Figure 96. 

In order to read records from or write records on 
Form D disk files, the programmer must perform the 
following operations: 

1. Place the access mechanism, module and track 
address of the next logical data record in subfield 
AMXxxx shown in Figure 96, and place the two digits 
that make this track address the record address of the 
next logical data record in subfield yy. (The iocs uses 
AMXXXX to issue the necessary Seek Disk instruction. 
It uses AMxxxxYY to cxccutc the desired read or write 
operation.) 

2. Make sure that the B-address of the input/output 
instruction in the top iorw on the File List associated 
with the affected file refers to the appropriate input/ 
output area. (Input/Output Request Words are dis- 
cussed under "Internal Use of the iocs.") 

3. Issue the nonsequential form of the desired get 
or PUT macro-instruction (e.g., put file,nseq). See 
"Disk Macro-Instructions" for a discussion of non- 
sequential macro-instructions. 

The IOCS cannot check for end-of-physical-unit or 
end-of-file conditions on this type of file. 
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A Form E (Sequential-Nongeometric) disk file is a 
single-record disk file organized in such a way that: 
(a) the IOCS can increment the current track address 
by one to obtain the address of the next track from 
which data records are to be read or written, (b) the 
first four digits of the address of each record of the 
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file are not necessarily identical to the first four digits 
of the address of the disk track on which the record 
resides, (c) each track of the file contains the same 
number of data records, and (d) the two low-order 
digits of the record address either are not in ascending 
numerical sequence or do not start with 00. 

The second operand of the dtf fileform entry must 
be included for this type of file. This operand is dis- 
cussed under "Form C." 

The DTF FILEFORM entry for this type of file must 
also include a third operand. The required third oper- 
and is NGEOM. An example of how this entry is coded, 
including this third operand, is shown in Figure 97. 



Track Address Field Record Address Field 



Line 
s s 


Label 

6 IS 


Operation 

18 20 


21 25 30 


35 


^A 


0,1, 


F.T.l.e.P.o\/fM . 




/.■,.2.3,M(i.e.aM. \ 


0,?, 


1 
. 1 1 J 1 1 > 1 I 


, , , , 


, i 



Figure 97. fileform Entry ( Second and Third Operands 
Included ) 



The DTF SCRAMBLE entry must be included in the 
DTF statement for this type of file. The operand of the 
SCRAMBLE entry is the label of a user-written routine 
(i.e., scramble routine) that provides the iocs with the 
address of the next data record that is to be read 
from or written on the file. An example of how this 
entry is coded is shown in Figure 98. 
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F'igure 98. scramble Entry 

When a request for a read or write operation against 
a Form E disk file is noted, the iocs performs the fol- 
lowing operations: 

1. Places the B-address of the requested input/out- 
put operation in index register 15. 

2. Moves the current track address (updated if 
necessary) into both the affected Track Address Field 
and Record Address Field (Figure 99). (The iocs 
follows the updating procedure outlined under "Form 
C" for this type of file.) 

3. Causes a branch to be taken to the scramble 
routine provided for the file. 

The user's scramble routine must then: (a) compute 
the address of the proper data record, (b) place this 
address in the relevant portion of the affected Record 
Address Field (see Figure 99), and (c) cause a branch 
to be taken back to the iocs at /scr/. 

Note: The user's scramble routine can neither make 
use of IOCS macro-instructions nor cause the using 
program to enter Priority Alert. (The using program 
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Figure 99. Input/Output Areas ( Form E Disk Files ) 

is removed from Priority Alert when the iocs passes 
control to the user's scramble routine.) 

Input/output areas associated with Form E disk 
files must conform to the format shown in Figure 99. 
The DA statements used to define these areas are 
shown in Figure 100. 
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Figure 100. da Statements for Forms E and F Disk Files 

The iocs supplies the information contained in the 
Track Address Field and Record Address Field shown 
in Figure 99, with one exception. The programmer 
must provide the information contained in the current 
record address portion of the Record Address Field. 

When the current track address of this type of file 
has been incremented to the point where it is one 
higher than the address of the last track of the phy- 
sical unit currently assigned to the file, the iocs per- 
forms the same operations it performs for Form A 
disk files in this situation. 

FORMF 

A Form F disk file (Nonsequential — Nongeometric) 
is a single-record disk file organized in such a way 
that: (a) the iocs cannot increment the track address 
by one to obtain the address of the next track from 
which records are to be read or written, and (b) the 
first four digits of the address of each record of the 
file are not identical to the first four digits of the ad- 
dress of the disk track on which the record resides. 

The DTF FILEFORM entry for this type of file must 
include the third operand discussed under "Form E." 
The second operand of the fileform entry discussed 
under "Form C" is not applicable and must be omitted. 
However, the comma that would normally separate the 
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second operand from the third operand must be in- 
cluded. An example of how the fileform entry is 
coded, if the third operand is included and the second 
is omitted, is shown in B^igure 101. 
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Figure 101. fileform Entry (Second Operand Omitted, Third 
Operand Included ) 



Input/output areas associated with this type of file 
must conform to the format shown in Figure 102. 
The DA statements used to define these areas are 
shown in Figure 100. 

The programmer must supply all the information 
contained in the Track Address Field and Record 
Address Field, shown in Figure 102. 
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B-Address of Input/Output Instructions 
Referencing This Area 



To read data records from or write data records on 
Form F disk files, the programmer must perform the 
operations described under "Form D." 

The IOCS makes no check to determine if an end-of- 
physical-unit or end-of-file condition has occurred on 
this type of file. 

FORMG 

A Form G (Partitioned Sequential-Geometric) disk file 
is a single-record disk file organized in such a way 
that: (a) the iocs is to read or write only one data 
record per disk track, (b) the record that is to be read 
or written occupies the same relative position on each 
track (e.g., every record of the file is the second record 
on the track that contains it), and (c) the iocs is to 
increment the current track address by one to obtain 
the address of the next record that is to be read or 
written, and the address of the track on which that 
record resides. 



The programmer specifies that a file is a Form G 
disk file by entering 1 as the operand of the dtf order 
entry for the file, and by omitting the second and third 
operands of the dtf fileform entry for the file. 

Input/output areas associated with this type of file 
must conform to the format shown in Figure 103. The 
DA statements used to define these areas are shown in 
Figure 94. 

Track/Record Address Field 
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Figure 103. Input/Output Areas ( Form G Disk Files ) 

All the information shown in the Track/Record 
Address Field in Figure 103 is supplied by the iocs. 

When the current track address of this type of disk 
file has been incremented to the point where it is one 
higher than the last track of the physical unit cur- 
rently assigned to the file, the iocs performs the same 
operations it performs in this situation for Form A 
disk files. See the discussion of "Form A." 

Single-Record Disk File Summary: A summary of 
the characteristics of the various types of single-record 
disk files is shown in Figure 104. 

Note: The iocs cannot process Form C, E, and F 
disk files unless the operand 7 appears in the seventh 
operand field of the iokdf macro-instruction at System 
Generation. No such restriction applies to Form 
A, B, D, or G disk files. 

Disk Macro-Instructions 

All get and put macro-instructions, except those used 
exclusively for punched card or printer files (i.e., put 

FILE,d; PUT WORK TO FILE,d; and PUT FILE TO FILE,d), 

can be issued against disk files. However, get and put 
macro-instructions issued against Form B, D, or F disk 
files must include an additional operand. This operand 
is NSEQ. It must be separated from the preceding oper- 
and by a comma. An example of how the nseq operand 
is included is shown in Figure 105. 
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Figure 104. Single-Record Disk File Summary 
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Internal Operation of the IOCS 



This section provides descriptions of certain aspects 
of the internal operation of the iocs. The following 
topics are discussed: Input/Output Request Word 
(lORw), System Monitor, File Table, iocs Lists, and 
IOCS Error Procedures. 



Input I Output Request Word (lORW) 

The lORW is a group of contiguous fields normally 
generated by the iocs. (See Figure 106.) These fields 
contain the information needed to define a specific 
input/output operation, and the status of that opera- 
tion at any given point during execution of the user's 
program. This information is normally provided by the 
IOCS, by DTF entries, and by the System Monitor. 

LINK FIELD 

This is a five-position field that Hnks together all the 
lORw's that appear on the same iocs List. It contains 
the address of the low-order position of the Link Field 
of the next iorw on the same list. The Link Field of 
the last IORW on a given list contains 00000. 

FILE LIST ADDRICSS FIELD 

This is a five-position field that associates each iorw 
with the File Table of a particular file. It contains the 
address of the low-order position of the File List 
Origin (i.e.. Field 5 of the relevant File Table). This 
address may be referred to by the name of the file 
(i.e., the label specified in the operand of the dtf 
Header Line entry for the file). 

input/output operation FIELD 

This is a ten-position field that contains a machine- 
language input/output instruction which the iocs 
schedules and executes. The B-address of this instruc- 
tion ties the iorw to a specific input/output area (i.e., 
the B-address of this instruction is the high-order posi- 
tion of the relevant input/output area). 

error count FIELD 

This is a two-position field. When an error results 
from execution of the instruction that appears in the 
Input/Output Operation Field, the iocs uses this field 



to maintain a count of the number of times the in- 
struction has been re-executed while attempting to 
correct the error. 

S (channel status character) FIELD 

This is a one-position field. The iocs places a character 
in this field when execution of the instruction that ap- 
pears in the Input/Output Operation Field results in 
an error. The bcd code of this character (i.e., the 
Channel Status Character) indicates the channel status 
indicators that were turned on by the error, with two 
exceptions. These exceptions are: (a) the B bit is not 
included in the bcd code of this character if the wlr 
operand of the dtf errcheck entry was omitted, even 
if the wrong-length-record indicator is on, and (b) if 
the relevant input/output operation was a disk opera- 
tion and no data was actually transferred by the opera- 
tion, the 1 bit is included to indicate that this is the 
case, even though the Not Ready channel status indi- 
cator was not turned on by the operation. 

D (channel test character) field 
This is a one-position field. The character (i.e., the 
Channel Test Character) in this field becomes the 
d-modifier of a Branch External Indicator (bex) in- 
struction. 

The IOCS uses this instruction to test for error condi- 
tions after execution of the instruction that appears in 
the Input/Output Operation Field. 

If the WLR operand of the dtf errcheck entry was 
specified for the file, and the file consists of Form 1 
or Form 2 records, the Channel Test Character is a 
group mark (+). If the wlr operand was not speci- 
fied, or if the file consists of Form 3 or Form 4 
records, this character is a segment mark (-§-). If the 
fourth operand of the errcheck entry was specified, 
this character is the character that appears as that 
operand. 

IORW INDICATORS 

Fields Ql through Q6 are one-position fields. Each 
of these fields contains a single character. The bcd 
code of these characters is used to control the internal 
operation of the iocs. The bits these characters may 
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contain and the significance of each bit are summa- 
rized in Figure 107. 

The bits associated with each box shown in Figure 
107 are mutually exclusive (e.g., if the B bit appears, 
the A bit may not appear). The bit associated with 
boxes marked spabe is always the low-order bit shown 
(i.e., A, 4, or 1). The programmer must keep this fact 
in mind if he plans to construct iorw's himself. A 
similar situation applies to the box marked internal. 
However, once the iorw is in use, the iocs may alter 
these bits. 

In the paragraphs that follow, Fields Q1-Q6 are 
discussed in detail. 

Ql: This field is reserved for the future use of the 

IOCS. 

Q2: The bcd code of the character in this field in- 
cludes the 8 bit if the second operand of the dtf 
FiLEFORM entry was specified. If the bcd code includes 
the 4 bit, this operand was not specified. The bcd code 
of the character in this field includes the 2 bit if the 
NGEOM operand was specified in the filefobm entry 
for the file (i.e., the file is a Form E or Form F disk 
file). If the BCD code includes the 1 bit, the ngeom 
operand was not specified. 

Q3: The bcd code of the character in this field in- 
cludes the B bit if a user-written error routine has 
been provided for the file with which the iorw is 
associated. If the bcd code includes the A bit, no such 
routine has been provided. (See the dtf "erraddr" 
entry.) 

The BCD code of the character in this field includes 
the 2 bit if a user-written service routine has been 
provided for the file with which the iorw is associated. 



If the BCD code includes the 1 bit, no such routine has 
been provided. ( See the dtf "intaddr" entry.) 

Q4: The bcd code of the character in this field in- 
cludes the B bit if the input/output area associated 
with the IORW has been released to the program (i.e., 
the TraflSc is on). The bcd code includes the A bit 
if the associated input/output area has not been re- 
leased to the program (i.e., the Traffic Bit is off). (See 
"Interaction of the iocs Lists" for a discussion of when 
the Trafiic Bit is set on and off. ) The bcd code of the 
character in this field includes the 2 bit if the iocs is 
to make a programmed wrong-length-record check 
after execution of the instruction in the Input/Output 
Operation Field. If the bcd code includes the 1 bit, this 
check is not made. ( See the dtf "errcheck" entry.) 

Q5: The bcd code of the character in this field in- 
cludes the B bit (i.e., the Exception Bit is on) if: (a) 
an error or end-of-reel condition has occurred as a 
result of execution of the instruction that appears in 
the Input/Output Operation Field, and (b) an exit is 
to be taken as a result of this condition to the error 
or end-of-file routine provided for the file by the pro- 
grammer. If the BCD code includes the A bit (i.e., the 
Exception Bit is off), no error or end-of-reel condi- 
tion has occurred. 

The BCD code of the character in this field includes 
the 2 bit if the iocs is to store the contents of the E- 
address or F-address register after execution of the 
instruction that appears in the Input/Output Opera- 
tion Field. If the bcd code includes the 1 bit, no such 
action is to be taken. ( See the dtf "errcheck" entry.) 

Note: If the bcd code of the character in Field Q4 
includes the 2 bit, the code of the character in Field 
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Q5 also includes the 2 bit. If the bcd code of the char- 
acter in Field Q5 includes the 2 bit, the bcd code of the 
character in Field Q4 does not necessarily include the 
2 bit. 

Q6: The bcd code of the character in this field in- 
cludes the B bit if: (a) an error condition resulted from 
execution of the instruction in the Input/Output Oper- 
ation Field, and (b) an exit is to be taken, as a result 
of this error condition, to the error routine provided for 
the file by the programmer. If the bcd code includes 
the A bit, no such error condition has occurred. 

The BCD code of the character in this field includes 
the 2 bit if the iocs is to make a Write Disk Check 
after execution of the instruction in the Input/Output 
Operation Field. If the bcd code includes the 1 bit, 
this check is not made. ( See the dtf "errcheck" entry.) 

Note: If the bcd code of the character in Field Q6 
includes the B bit, the code of the character in Field 
Q5 also includes the B bit. However, it should be noted 
that the converse is not necessarily true. 

ADDRESS REGISTER FIELD 

This is a five-position field. It is generated: (a) if the 
WLR operand of the dtf errcheck entry was specified 
for the relevant file and the file consists of Form 3 or 
Form 4 records, or ( b) if the store operand of the dtf 
errcheck entry was specified for the relevant file, re- 
gardless of the record form used by the file. 

The IOCS stores, in this field, the length of the last 
record read after execution of the instruction that ap- 
pears in the Input/Output Operation Field if: (a) the 
file consists of variable-length records, and ( b) the wlr 
operand was specified for the file. (The iocs compares 
the contents of this field to the contents of the relevant 
Block Character-Count to determine if a wrong-length 
record has been read.) In all other cases, the iocs stores 
the contents of the E-address or F-address register in 
this field after execution of the relevant input/output 
operation. 



User-Coded lORW's 

The programmer can create an iorw by providing 
coding of the format shown in Figure 108. 

The operand shown on Line 1 of Figure 108 must be 
either 00000 or the address of the low-order position 
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of the Link Field of another iorw. The units position 
of this field must always be signed plus. The operand 
shown on Line 2 must be the name of the file (as it 
appears in the operand of the relevant dtf Header Line 
entry) with which the iorw is to be associated. The 
operands shown on Line ^S^must be ( in order) the x- 
control field, the B-address (i.e., the label referring 
to the appropriate input/output area), and the d-modi- 
fier of the instruction that is to appear in the Input/ 
Output Operation Field of the iorw. The operand 
shown on Line 4 reserves the ten positions of core stor- 
age needed to contain the Error Count, the S„ the D, 
and the Q fields of the iorw. The first three positions 
(i.e., the Error Count and S fields) must contain blank 
characters. The last seven positions should contain the 
actual characters the programmer wants to appear in 
the D field and the Q fields. The operand shown on 
Line 5 is required only if the Address Register Field 
is to appear. 

Any iorw created by the programmer can be associ- 
ated with the relevant file by means of the dtf filelist 
entry. 

The following restrictions apply to user-coded 
lORw's : 

1.. The Traffic Bit must be on if the file is not to be 
opened before it is used (i.e., the bcd code of the char- 
acter in Field Q4 includes the B bit, but not the A bit). 

2. The low-order character of the x-control field of 
the instruction in the Input/Output Operation Field 
cannot be or 3 if the instruction is a disk instruction. 

Modification of the IORW 

The contents of any field of an iorw can be modified 
during execution of the program, as long as the modi- 
fication preserves the intent of the field. 



System Monitor 

The System IVIonitor provides the iocs with the follow- 
ing information: 

1. If a file uses a unit-record device, the System 
Monitor provides a character indicating the channel 
to which that device is attached ( i.e., the channel char- 
acter). This character is placed in the x-control field 
portion of the Input/Output Operation Field of each 
IORW on the File List associated with the file. 

2. If a file uses a magnetic tape unit, the System 
Monitor provides: (a) the number of the unit, and 
(b) a character indicating the channel to which the 
unit is attached. This information is placed in the x- 
control field portion of the Input/Output Operation 
Field of each iorw on the File List associated with 
the file. 
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3. If a file uses a module of 1301 or 2302 Disk Stor- 
age, the System Monitor provides: (a) a character indi- 
cating the channel to which the module is attached, 
(b) the address of the first track of the physical unit 
currently assigned to the file, and (c) the Ending 
Track Address of the physical unit currently assigned 
to the file. This information is placed, respectively, in: 
(a) the x-control field portion of the Input/Output 
Operation Field of each iokw on the File List associ- 
ated with the file,' (b) Field 3 of the File Table asso- 
ciated with the file, and (c) Field 4 of the File Table 
associated with the file. 

The IOCS automatically links with System Monitor 
to obtain this information whenever: 

1. A file is opened by means of an ioctl open macro- 
instruction. 

2. An end-of-reel condition occurs on a tape file for 
which an alternate unit (or units) has been specified. 

3. An end-of -physical-unit condition occurs on a disk 
file for which an alternate physical unit ( or units) has 
been specified. 

The information provided by the System Monitor 
di£Fers as follows : 

1, When a file is opened, the information provided 
refers to the Base Unit assigned to the file. 

2. When an end-of-reel or physical-unit condition 
occurs on a file, the information provided refers to the 
next alternate unit (if any). 

Monitor Calling Sequences 

The System Monitor can provide the information dis- 
cussed above at times other than when a file is opened, 
or an end-of-reel or end-of-physical-unit condition oc- 
curs on a file. To obtain this information at times other 
than those noted above, the programmer must enter 
the appropriate System Monitor calling sequences in 
his object program. The various System Monitor call- 
ing sequences are discussed in the material that follows. 

base/current sequence 

The Base/Current sequence causes the System Moni- 
tor to establish the Base Unit associated with the file 
as the Current Unit of the file. This sequence consists 
of the coding shown in Figure 109. 

The label filename shown on Line 1 must be the 
same label that appears in the operand field of the 
DTF Header Line entry for the aflFected file. 
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Figure 109. Base/Current Sequence 
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alternate/current sequence 

The Alternate/Current sequence causes the System 
Monitor to establish the next Alternate Unit associated 
with the file as the Current Unit of the file. This se- 
quence consists of the coding shown in Figure 110. 
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Figure 110. Alternate/Current Sequence 

The label anylabel shown on Line 3 of Figure 110 
refers to a user-written routine that is to be exited to 
if there is no Alternate Unit available to be estab- 
lished as the Current Unit. When this exit is taken, 
the System Monitor automatically establishes the Base 
Unit as the Current Unit. 

USE current unit sequence 

The Use Current Unit sequence must be entered in the 
user's source program subsequent to the coding for the 
Base/Current sequence or the Alternate/Current se- 
quence (whichever is appropriate). The exact point at 
which the Use Current Unit sequence is entered is not 
critical, as long as it appears in the user's object pro- 
gram: ( a) after the relevant Base/Current or Alternate/ 
Current sequence, and (b) before the next get or put 
macro-instruction that references the affected file. The 
Use Current Unit sequence consists of the coding 
shown in Figure 111. 
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Figure 111. Use Current Unit Sequence 

File Table 

The File Table is a group of fields that contain in- 
formation the IOCS must have to schedule and execute 
input/output and related operations on a file. The 
information contained in the File Table is provided 
by DTF entries and the System Monitor. When a dtf 
statement is not provided for a file, the programmer 
must construct the File Table for that file, and hand 
code any get or put macro-instructions to be issued 
to that file. 

The fields of the File Table (Figure 112) are dis- 
cussed in the section that follows. 

Tape/Disk Prefix 

The File Table Tape/Disk Prefix consists of Fields 1-4. 
If the file is a tape file, all four fields appear. If the file 
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is a disk file and the second and third operands of the 
DTF FiLEFORM entry have been specified for the file, all 
four fields appear. If the file is a disk file and the sec- 
ond, but not the third, operand of the dtf fileform 
entry has been specified for the file, both subfields of 
Field 2 appear, as do Fields 3 and 4. For all other disk 
files, only the second subfield of Field 2, and Fields 3 
and 4 appear. 

FIELD 1 

For Form E disk files, this is a five-position field that 
contains the address of the programmer's scramble 
routine. For all other types of disk files, this field is 
omitted. For tape files that use labels the iocs is to proc- 
ess, this is a five-position fitjld that contains the address 



of the File Table Extension that is to be used to process 
the labels of the file. For all other tape files, this is a 
one-position field that contains a 0. 

FIELD 2 

For Forms C and E disk files, this is a four-position 
field. In this case the first two positions of this field 
are a subfield that contains the number specified as 
the second operand of the dtf fileform entry; the last 
two positions are a subfield that initially contains zeros. 
Every time a disk record is read or written, the integer 
1 is added to the second subfield. When the number in 
the second subfield equals the number in the first sub- 
field, the second subfield is reset to contain zeros, and 
the Current Track Address ( Field 3 ) is incremented by 1. 
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If the file is a Form A, B, D, F, or G disk file, this is 
a two-position field that is reserved for the internal use 
of the IOCS. For tape files, this is a five-position field that 
contains a count of the records (unblocked files) or 
blocks of records ( blocked files) read from or written 
on the current reel of tape. Noise records (i.e., records 
less than 13 characters in length), header and trailer 
labels, and tape marks are not included in this count. 



FIELD 3 



For disk files, this is an eight-position field that con- 
tains the information shown in Figure 113 (i.e., the 
Current Track Address of the current physical unit). 
This information is initially supplied by the System 
Monitor. 



A M TTTT HA 



I 
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Track Address 

Module 

•Access Mechanism 



Figure 113. Current Track Address 

For input tape files, this is a two-position field that 
initially contains zeros. The programmer may place 
a signed or unsigned positive integer in this field that 
represents the number of reels that make up the file. 
Every time the iocs reads a complete reel of the file, 
it decrements this integer by 1. When this field con- 
tains all zeros, the iocs causes a branch to be taken to 
the programmer's end-of-file routine. If this field has 
been set to a positive integer by the programmer, the 
IOCS ignores any lEorb or lEonb label identifier en- 
countered in the trailer label of a reel of the file. If the 
file is an output tape file, this field is not referenced by 
the IOCS. 

FIELD 4 

This is a four-position field. For disk files, this field 
contains the address (i.e., the End Track Address) of 
the last track of the current physical unit that is to 
be read or written by the iocs. This address is pro- 
vided by the System Monitor. It must be in the same 
module as the first track of the current physical unit. 
The IOCS uses this field to determine when the last track 
of the current physical unit has been read or written. 
For tape files, this field contains the characters spe- 
cified in the four operand fields of the dtf rwdoptns 
entry. 

File Table Body 

The File Table Body consists of Fields 5-16. These 
fields appear regardless of the type of input/output 
device used by the file. 



FIELD 5 

This is a five-position field that is referred to as the File 
List Origin. It contains the address of the low-order 
position of the first iorw Link Field on the associated 
File List. ( See the discussions of List Origin and File 
List, under "The iocs Lists.") The units position of this 
field may be referred to by the label entered as the 
operand of the dtf Header Line entry for the file. When 
there are no iorw's on the File List, this field contains 
00000. 

field 6 

This is a five-position field that contains the address 
equivalent of the symbolic unit name entered as the 
second operand of the dtf symunit entry. This ad- 
dress is used by the System Monitor to provide certain 
information that is inserted in the iorw's associated 
with the file. (See the section "System Monitor.") If 
the file is a disk file, the System Monitor also uses this 
field to provide the information contained in Fields 
3 and 4. 

field 7 

This is a five-position field that contains the address of 
the programmer's end-of-file routine. If the dtf eofaddr 
entry is omitted, this field contains the address of the 
unusual-end-of -program routine in the System Monitor 
(i.e., Dcw /uEp/). Thus, an end-of-file condition will 
result in a branch to /uep/. 

FIELD 8 

This is a six-position field that contains the File Indi- 
cators F1-F6. Each indicator is a single character ( see 
Figure 114). The bits associated with the boxes marked 
SPARE in Figure 114 are always the low-order bits 
shown (i.e.. A, 4, or 1). The bits associated with each 
box are mutually exclusive (e.g., if the 4 bit appears, 
the 8 bit may not appear). The file indicators are dis- 
cussed in the paragraphs that follow. 

Fl: This indicator is the character specified by the 
DTF PADCHAR cutry Written for the file. It is a blank 
character (b) if the padchar entry is omitted. 

F2: If the BCD code of this indicator includes the B 
bit, the Error Accept bit is said to be on. If the bcd 
code includes the A bit, the Error Accept bit is said 
to be OFF. The iocs sets the Error Accept bit on just 
before exiting to the error routine the user has pro- 
vided for the file. If the programmer does not set the 
Error Accept bit off before exiting from this error 
routine, the iocs, immediately after the error routine 
has been exited from, accepts the results of the input/ 
output operation, the execution of which caused the 
error routine to be entered. The iocs does this by set- 
ting the Traffic Bit of the afifected iorw ( i.e., the iorw 
that is then at the top of the File List associated with 
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Figure 114. File Indicators 



the file) OFF and placing the iorw on the bottom of the 
File List of the afiFected file. If the programmer does 
set the Error Accept bit off before exiting from his 
error routine, the iocs, immediately after the error rou- 
tine has been exited from, re-executes the input/output 
operation, the execution of which caused the error 
routine to be entered. 

F3: When this indicator is assembled, its bcd code 
includes the A bit. If the user replaces this A bit with 
a B bit, closes and then reopens the file, the System 
Monitor assigns to the file the last physical unit refer- 
enced by the file. (Normally, the System Monitor as- 
signs the Base Unit to a file when the file is opened.) 

The BCD code of this indicator includes the 1 bit when 
it is assembled. If the user replaces this bit with a 2 bit 
and an end-of-reel or physical-unit condition is forced 
or encountered on the file, the next alternate physical 
unit is not assigned to the file by the System Monitor, 
as would normally be the case. Instead, the System 
Monitor assigns to the file the last physical unit refer- 
enced by the file prior to the end-of-reel or physical- 
unit condition. In addition, if the file is a disk file, the 
IOCS will cause a branch to be taken to the user's end- 
of-file routine for the file. 

F4: If the bcd code of this indicator includes the B 
bit, the SKIP operand of the dtf erroptns entry has 
been specified for the file. If the bcd code includes the 
A bit, the accept operand of the dtf erroptns entry 
has been specified for the file, or the erroptns entry 
has been omitted altogether. If the bcd code of this 
indicator includes the 2 bit, the dtf fileform entry 



for the file specified that the file consists of Form 4 
data records. If the bcd code includes the 1 bit, the dtf 
FILEFORM entry for the file specified that the file con- 
sists of Form 1, 2, or 3 data records. 

F5: If the bcd code of this indicator includes the B 
bit, an error or end-of-file condition has occurred on 
the file as a result of the last input/output operation 
performed on the file. If the bcd code includes the A 
bit, no such condition occurred as a result of the last 
input/output operation. If the bcd code of this indi- 
cator includes the 2 bit, the dtf fileform entry speci- 
fied that the file consists of blocked data records ( i.e.. 
Form 2 or Form 4). If the bcd code includes the 1 bit, 
the dtf fileform entry specified that the file consists 
of unblocked records (i.e.. Form 1 or Form 3). 

F6: This indicator notifies the iocs what type of 
input/output device is to be used by the file. This in- 
formation is obtained from the dtf symunit entry. 

The possible device indicators are: 



INDICATOR 

1 

2 
4 



EXPLANATION 

1402 Card Reader, 1442 Serial Card 
Reader, 1011 Paper Tape Reader 
1402 Card Punch, 1403 Printer 
7330, 729 Magnetic Tape Units 
1301 or 2302 Disk Storage 



FIELD 9 



This is a two-position field. It contains the last two 
digits of the address of the index register specified in 
the DTF INDEX entry. If the dtf index entry is omitted, 
this field contains zeros. 
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FIELD 10 

This is a five-position field that initially contains zeros. 
If the DTF INDEX entry was specified, this field contains 
the high-order address of the input/output area cur- 
rently available to the user's object program. If the dtf 
INDEX entry was not specified, this field contains : (a) the 
high-order address of the data record currently avail- 
able to the using program, if the file is an input file, or 
(b) the high-order address of that portion of the cur- 
rent output area that is available to the using program, 
if the file is an output file. The iocs provides this in- 
formation during execution of get; put; ioctl open, 

OUTPUT; IOCTL RELSE,OUTPUT; and IOCTL FEOR. 

If an exit has been taken to a user-written error or 
end-of-file routine, this field contains the return ad- 
dress to the series of instructions generated by the get 
or PUT macro-instruction that caused the exit to be 
taken. 

FIELD II 

This a five-position field that contains the information 
entered in the operand of the dtf blocksize entry. If 
the file consists of Form 1 or Form 3 records, this field 
is not used by the iocs. In these instances, the pro- 
grammer is free to make use of this field for his own 
purposes. For Form 4 records, this field contains the 
operand of the dtf blocksize entry plus one. 

field 12 

This is a five-position field. If the file is an input file 
made up of Form 2 or Form 4 records, it contains the 
low-order address +1 of the block of data records cur- 
rently available to the using program. (The iocs uses 
this information during execution of get, put, ioctl 
OPEN, IOCTL close, and ioctl feor.) If the file is an out- 
put file: (a) that is made up of Form 4 records, (b) for 
which the dtf length entry has been specified, and 
(c) that is to be processed by the put file,form4 
macro-instruction, the programmer places in this field 
the length of the next record he is going to move into 
the current output area. (Under these conditions this 
field may be referred to symbolically by the operand 
of the dtf length entry.) The two high-order positions 
of this field are also used by the iocs as temporary stor- 
age for the last two characters of the current get/put 
calling sequence (i.e., the coding generated by the cur- 
rent get or put). 

field 13 

This is a four-position field. If the file consists of Form 
2 records, this field contains the information entered in 
the operand of the dtf recsize entry. If the file is an 
output file that consists of Form 4 records, this field 
contains an integer equal to the number of positions 
in the current output area of the file that are occupied 
by data. 



This field is not used by the iocs if the file consists 
of Form 1 or Form 3 records, or if the file is an input 
file that consists of Form 4 records. In these instances, 
the programmer is free to make use of the field for 
his own purposes. 

field 14 

This is a five-position field that contains the informa- 
tion entered in the second through sixth operands of 
the dtf erraddr entry. (The mnemonic used by the 
IOCS to generate a character for this field is new, if the 
corresponding operand calls for an exit bypassing 
standard iocs error procedures. It is dc, if the corre- 
sponding operand calls for an exit only when the error 
condition or conditions specified cannot be corrected 
by the standard iocs error procedures.) The iocs uses 
this information to determine under what conditions 
it is to branch to the error routine provided by the 
user for the file. This field must contain blanks if the 
DTF erraddr entry is omitted. 

field 15 

This is a five-position field that contains the address of 
the error routine the programmer has provided for the 
file. (This field can be used by the programmer for 
his own purposes if the dtf erraddr entry is omitted 
and the dtf intaddr entry is included. If both dtf 
ERRADDR and INTADDR entries are omitted, this field 
does not appear.) 

FIELD 16 

This is a five-position field that contains the address of 
the service routine the programmer has provided for 
the file. This field does not appear if the dtf intaddr 
entry is omitted. 

File Table Extension 

The File Table Extension consists of Fields 17-25. The 
iocs uses the information contained in these fields to 
process the tape labels used by the file. If the file does 
not use labels, these fields do not appear. Most of the 
information contained in these fields is provided by 
the DTF LABEL and check entries for the file (e.g., the 
LABEL entry supplies the information for Fields 21-25). 
The programmer may update or alter the information 
contained in these fields (see "Appendix E"). When 
these fields are generated, they precede the balance 
of the File Table in core storage, but they do not 
necessarily immediately precede the balance of the 
File Table. 

FIELD 17 

This is a one-position field that contains a character 
normally supplied by the iocs. This character is used 
to terminate the table lookup operations the iocs per- 
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forms on Field 18. If the programmer has specified the 
DTF lineI above entry for the file, that entry supplies 
this character. 



FIELD 18 

This field contains from one to eight entries if the 
DTF lineI or line2 entries have been specified; from 
9 to 16 entries if lineI above was specified. Each 
entry consists of a dcw followed by a DC. The dcw 
specifies the address of a label routine written by the 
user. The dc specifies the point in the iocs tape label 
routines at which the iocs is to branch to that routine. 

FIELD 19 

This is a five-position field that contains the Label 
indicators Ll-L,5. Each of these indicators consists of 
a single character. (See Figure 115.) The bits associ- 
ated with the boxes marked spare in the figure are 
always the low-order bits shown (i.e., A, 4, or 1). The 
bits associated with each box are mutually exclusive 
(e.g., if the 2 bit appears, the 1 bit may not appear). 

The label indicators are discussed in the material 
that follows. 

LI: The bcd code of this indicator includes the 2 bit 
if the file serial number has been entered as an op- 
erand of the DTF label entry. The bcd code includes 
the 1 bit if the file serial number has not been entered. 
(If the BCD code includes the 1 bit and the file is a 
tape output file, the iocs places the reel serial number 
of the first reel of the file in Field 24 of the File Table 
prior to writing the new output header label. If the 
BCD code includes the 2 bit, the iocs places the speci- 
fied file serial number in Field 24.) 

L2: The bcd code of this indicator includes the B 
bit if NONSTD appears as the second operand of the 
DTF label entry for the file. If the file uses standard 



labels, the bcd code of this indicator includes the A 
bit. The bcd code of this indicator includes the 2 bit 
if 120 appears as the first operand of the dtf label 
entry for the file. The bcd code includes the 1 bit if 
80 appears as the first operand, or the dtf label entry 
was not specified for the file. 

L3: The bcd code of this indicator includes the B bit 
if the SER operand is specified in the dtf check entry 
for the file. The bcd code includes the A bit if this 
operand is not specified, or the dtf check entry was 
not specified for the file. The bcd code of this indicator 
includes the 2 bit if the id operand is specified in the 
DTF CHECK entry for the file. The bcd code includes the 
1 bit if this operand is not specified or the check entry 
was omitted. 

L4: The bcd code of this indicator includes the B bit 
if the SEQ operand is specified in the dtf check entry 
for the file. The bcd code includes the A bit if this 
operand is not specified, or the check entry was 
omitted. 

The BCD code of this indicator includes the 2 bit if 
the DAT operand is specified in the dtf check entry 
for the file. The bcd code includes the 1 bit if this 
operand is not specified, or the check entry was 
omitted. 

L5: The bcd code of this indicator includes the B bit 
if the CNT operand is specified in the dtf check entry 
for the file. The bcd code includes the A bit if this 
operand is not specified, or the check entry was omit- 
ted. The BCD code of this indicator includes the 2 bit if 
the ret operand is specified in the dtf check entry for 
the file. The bcd code includes the 1 bit if this operand 
is not specified, or the check entry was omitted. 

ALL: If the all operand is included in the dtf check 
entry for the file, the bcd code of indicators L3, L4, 
and L5 is B-4-2. 
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FIELD 20 



This is a one-position field that contains a character 
indicating the form of the records on the file. F indi- 
cates Form 1, W indicates Form 2, B indicates Form 
3, and X indicates Form 4. 

FIELD 21 

This is a four-position field that contains the retention 
period. If the file uses 80-character labels, the high- 
order position of this field contains a — . 

FIELD 22 

This is a five-position field that contains the creation 
date. 

FIELD 23 

This is a ten-position field that contains the file identi- 
fication. 

FIELD 24 

This is a five-position field that contains the file serial 
number. 

FIELD 25 

This is a four-position field that contains the reel se- 
quence number. If the file uses 80-character labels, 
the high-order position of this field contains a — . The 
reel sequence number is incremented by 1 at end "of 
reel, but it is not reset. When files of more than one 
reel are closed and reopened, the user can reset this 
number if required. 

IOCS Lists 

An IOCS List is a collection of iorw's grouped by the 
IOCS for a specific purpose (e.g., to schedule assign- 
ment of access mechanisms to iorw's that represent 
requests for disk input/output operations). 

List Origin: Each iocs list has a List Origin. This 
is a five-position field that contains the address of the 
low-order position of the Link Field of the first iorw 
on that list, If the list is temporarily without iorw's 
the List Origin contains 00000. 

The Link Field of each iorw on an iocs list contains 
the address of the low-order position of the Link Field 
of the next iorw on the same list. There is one ex- 
ception to this rule. The Link Field of the last iorw 
on a list contains OOOOO or 00000. These zeros indicate 
to the IOCS that the end of the list has been reached. 

In addition to a List Origin, every Read/Write List 
maintains a List End Address. This is a five-position 
field that contains the address of the low-order posi- 
tion of the Link Field of the last iorw on the list. If a 
Read/Write List is temporarily without iorw's, the 
List End Address contains the address of the low-order 
position of the List Origin of that list. 



FILE lists 

One File List is associated with every File Table. 
(This is a function of the dtf ioareas or the dtf 
FiLELiST entry.) The iorw's on File Lists represent 
completed input/output operations. The input/output 
area associated with the first iorw on such a File List 
is the input/output area currently available to the 
user's program. The iorw's on File Lists are processed 
in the order in which they appear on these lists. The 
List Origins of File Lists are automatically generated 
in the File Tables with which the lists are associated. 

DISK MODULE LISTS 

There is one Disk Module List for each module of 
1301 or 2302 Disk Storage defined at System Genera- 
tion. The List Origins of these lists are contained in the 
Resident iocs. The iorw's on these lists: (a) represent 
requests for Seek Disk operations, or (b) indicate that 
the relevant Seek Disk operation, or its associated 
input/output operation, is in the process of being 
executed by the iocs. __ 

The last iorw on such a list contains OOOOO in its 
Link Field. (This is the only instance when OOOOO 
may appear in the Link Field of an iorw.) If the list 
is void, the List Origin of the list contains OOOOO. 

read/write lists 

The iocs maintains one Read/Write List for each data 
channel available to using programs. The iorw's on 
Read/Write Lists represent requests for input/output 
operations. They are normally processed in the order 
in which they appear on these lists. This is not the 
case, if: (a) a get or put other than a get,defer or 
put,defer is issued and (b) the iorw associated with 
the requested input/output operation is not available 
on the relevant File List. Under these conditions, the 
iocs causes the appropriate Read/Write List to be 
searched until the aflfected iorw is located. If the 
affected iorw is not at the top of the list, it is im- 
mediately moved to the top. This ensures that the 
requested operation is the next operation executed on 
the affected channel. The List Origins of Read/Write 
Lists are contained in the Resident iocs. 

service lists 

A Service List is associated with every service routine 
whose label appears as the operand of a dtf intaddr 
entry. The iorw's on these lists represent requests 
pending for entry into user-written service routines. 

The List Origins of these lists immediately precede 
the service routines with which they are associated. 
They may be referred to by the label of the relevant 
service routines. 
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PROGRAM LIST 

The IOCS maintains one Program List. The entries on 
this list are not iorw's. They are five-position fields 
that contain addresses which identify service routines 
that have iorw's on their associated Service Lists. The 
Resident iocs places these entries on the Program 
List, the most recent entry at the top of the list. This 
is a departure from the procedure followed in adding 
entries to the other iocs Lists. When a new entry is 
added to the other iocs Lists, it is added to the bottom 
of the list. 

When all the iorw's on the Service List of the rou- 
tine associated with the entry at the top of the Pro- 
gram List have been processed, the Resident iocs 
removes the affected entry from the Program List. It 
then places the next entry at the top of the list and 
causes the service routine associated with that entry 
to be entered. This process is repeated until the Pro- 
gram List is devoid of entries. When this occurs, the 
Resident iocs restores the status of the user's main- 
Hne program and causes a branch to be taken to the 
interrupted instruction in the user's main-line pro- 
gram. The List Origin of the Program List is in the 
Resident iocs. 

Interaction of ttie IOCS Lists 

The flow of iorw's between the iocs Lists is discussed 
in the paragraphs that follow. 

When the iocs encounters a get or put macro-in- 
struction in the user's program, the Resident iocs scans 
the appropriate File List until it encounters an iorw 
whose Traffic Bit is off. The Resident iocs then sets 
the Traffic Bit of the affected iorw on and makes the 
input/output area associated with the iorw available 
to the user's program. 

When the Resident iocs scans the File List, it sends 
all the iorw's whose Traffic Bits are on to the bottom 
of the appropriate Read/Write List. ( See Path 1, 
Figure 116.) 
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Figure 116. Interaction Between File Lists and Read/Write 
Lists 

Note: In the case of disk files, when the Resident 
IOCS scans a File List, it sends all the iorw's whose 
Traffic Bits are on to the proper Disk Module List, 
rather than to the appropriate Read/Write List. ( See 
Path 1, Figure 117.) 




Figure 117. Interaction of the File Lists and Disk Module Lists 

When an iorw that has been sent to a Read/Write 
List reaches the top of that list (i.e., the iorw's that 
preceded it have been processed and removed from 
the list), execution of the instruction in the Input/ 
Output Operation Field of the iorw is begun. The 
IORW is then removed from the Read/Write List and 
saved until execution of the relevant instruction has 
been completed. If execution of the instruction does 
not result in an error, the Resident iocs sets the Traffic 
Bit of the affected iorw off, and places it on the bot- 
tom of the relevant File List. (See Path 2, Figure 116.) 

If execution of the instruction resulted in an error 
condition, or combination of conditions, that the pro- 
grammer has specified are to cause the iocs to : (a) by- 
pass the normal iocs error correction procedures, and 
(b) exit to the error routine the programmer has 
provided for the file, the Resident iocs performs the 
following functions : 

1. Returns the affected iorw to the bottom of the 
appropriate File List. (See Path 2, Figure 116.) 

2. Removes all other iorw's associated with the 
affected file from the relevant Read/Write List ( start- 
ing at the top of the list), and places them (in the 
order in which they are removed) on the bottom of 
the File List. (See Paths 3 and 4, Figure 116.) 

If execution of the instruction resulted in an error 
condition, or combination of conditions, that the pro- 
grammer has specified are to cause the iocs to: (a) 
execute the normal iocs error procedures, and (b) 
enter the error routine the programmer has provided 
for the file only if the error or errors could not be cor- 
rected by the normal error procedures, the Resident 
IOCS: 

1. Performs the functions described in item 2 above, 
if the error condition or conditions could not be cor- 
rected, or 

2. Places the affected iorw on the bottom of the 
appropriate File List (see Path 2, Figure 116), if the 
error condition or conditions were corrected. 

If execution of the instruction resulted in an error 
condition, or conditions, for which the programmer 
has not specified an exit to the error routine he has 
provided for the file, the affected iorw is placed on 
the bottom of the appropriate File List (see Path 2, 
Figure 116). This is not the case, however, if the skip 
operand of the dtf erroptns entry was specified for 
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the file. If the skip operand was specified, the affected 
lORW is retained at the top of the appropriate Read/ 
Write List so that the relevant instruction can be re- 
executed by the iocs. 

If execution of the instruction: (a) did not result 
in an error condition, or combination of conditions, 
that the programmer has specified are to cause the 
IOCS to exit to the error routine the programmer has 
provided for the file, (b) did not result in an error 
condition of any kind if the skip operand of the dtf 
ERROPTNs entry has been specified for the file, and ( c) 
the programmer has specified that a user-written serv- 
ice routine has been provided for the file, the Resident 
IOCS takes the affected iorw off the top of the Read/ 
Write List (see Path 1, Figure 118) and places it on 
the bottom of the appropriate Service List. The Resi- 
dent IOCS then causes the service routine provided for 
the file to be entered. At this time, the Resident iocs 
sets the Traffic Bit of the iorw off. 

The programmer may perform any function he de- 
sires within a service routine; however, the last instruc- 
tion of every user-written service routine must be the 
lOCTL ExiT,ACCEPT or the locTL ExiT,DELETE macro- 
instruction. If the ioctl exit,accept is the last instruc- 
tion, the Resident iocs takes the affected iorw off the 
top of the relevant service routine Service List (see 
Path 2, Figure 118) and places it on the bottom of the 
appropriate File List. If the last instruction is ioctl 
exit,delete the Resident iocs notes: (a) that the 
IORW has been removed from the relevant Service List 
(see Path 3, Figure 118), and (b) that control of the 
IORW has been assumed by the user. 



File List 



Read/Write List 



ce List 




Figure 118. Interaction of File Lists, Read/Write Lists and 
Service Lists 



IOCS Error Procedures 

Upon completion of every input/output operation 
performed on a file, a bex ( Branch External Indicator) 
instruction is executed. The character found in the D 
(Channel Test Character) Field of the relevant iorw 
becomes the d-character of this instruction. 

If a branch is taken as a result of executing the hex 
instruction (i.e., a channel status indicator, whose as- 
sociated BCD bit matches a bit included in the bcd code 
of the d-character of this instruction, was turned on as 



a result of the input/output operation), the iocs Error 
Control routine is entered. If a branch is not taken, the 
next sequential instruction of the user's program is 
executed. 

Error Control Routine 

The primary function of the Error Control routine is 
to determine if and when a particular iocs error rou- 
tine is to be entered. The operation of the Error Con- 
trol routine, prior to entry into a particular iocs error 
routine, is: 

1. When control passes to the routine, it stores the 
Channel Status Character ( i.e., a character whose bcd 
code indicates which channel status indicators were 
turned on upon completion of the relevant input/ 
output operation) with appropriate alterations, in the 
S Field of the affected iorw. Alterations to the Chan- 
nel Status Character are discussed under "S (Channel 
Status Character) Field." 

2. The Error Control routine then attempts to match 
the Channel Status Character with one of the char- 
acters in Field 14 of the relevant File Table that is 
tagged with a word mark. 

3. If the Channel Status Character does not match 
a character in Field 14 that is tagged with a word 
mark, the Error Control routine causes a branch to be 
taken to the appropriate iocs error routine. 

4. If the Channel Status Character matches a char- 
acter in Field 14 that is tagged with a word mark, the 
Error Control routine examines indicator Q3 of the 
affected iorw to determine if a user-written error rou- 
tine has been provided for the relevant file. 

5. If no such routine has been provided, the iocs 
error routines are bypassed and the affected input/ 
output operation is processed as if it were error free. 

6. If a user-written error routine has been provided, 
the Error Control routine: (a) sets the Exception Bit 
and Error Bit in the affected iorw on, ( b ) places the 
affected iorw on the bottom of the relevant File List 
with its Traffic Bit set off, and (c) removes all the 
lORw's associated with the affected file from the ap- 
propriate Read/Write List (starting at the top of the 
list) and places them (in the order in which they were 
removed from the Read/Write List) on the relevant 
File List ( Traffic Bits set on). 

The Error Control routine also performs certain 
operations if an iocs error routine is unable to correct 
an error condition directed to it for correction. These 
operations are; 

1. When an iocs routiae cannot correct an error, 
control passes to the Error Control routine. This rou- 
tine attempts to match the Channel Status Character 
in the affected iorw with a DC-generated character in 
Field 14 of the relevant File Table. 
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2. If the Channel Status Character in the S Field of 
the lORW does not match a character in Field 14, the 
Error Control routine checks the fourth File Indicator 
( F4 ) of the relevant File Table. 

3. If the BCD code of F4 includes the B bit (i.e., the 
SKIP operand of the dtf erroptns entry has been speci- 
fied for the file), the Error Control routine retains the 
affected iorw at the top of the relevant Read/Write 
List with its Traffic Bit set on (i.e., schedules immedi- 
ate re-execution of the instruction that appears in the 
Input/Output Operation Field of the iorw). 

4. If the JBCD code of F4 includes the A bit (i.e., the 
ACCEPT operand of the dtf erroptns entry has been 
specified for the file, or the erroptns entry has been 
omitted altogether), the Error Control routine places 
the affected iorw on the bottom of the relevant File 
List with its Traffic Bit set off. 

5. If the Channel Status Character matches a char- 
acter in Field 14, the Error Control routine examines 
Field Q3 of the affected iorw to determine if a user- 
written error routine has been provided for the file. 

6. If such a routine has been provided, the Error 
Control routine: (a) sets the Exception Bit and the 
Error Bit in the affected iorw on, (b) places the af- 
fected iorw on the bottom of the appropriate File List 
with its Traffic Bit set off, and (c) removes all the 
lORw's associated with the affected file from the ap- 
propriate Read/Write List (starting at the top of the 
list) and places them (in the order in which they 



were removed from the Read/Write List) on the rele- 
vant File List ( Traffic Bits set on ) . 

7. If this routine has not been provided, the affected 
input/output operation is processed as if it were error 
free. 

Error Routines 

The IOCS provides an error routine for each type of 
input/output device specified by the using installation 
at System Generation. Each iocs error routine attempts 
to correct the error conditions routed to it for correc- 
tion by re-executing the relevant input/output opera- 
tions, or by other means peculiar to the affected type 
of input/output device. 

Whenever an iocs error routine causes an input/ 
output operation to be re-executed, the number in the 
Error Count Field of the affected iorw is incremented 
by one and the Channel Status Character of the iorw 
is replaced with a blank character. If the error recurs, 
the operation is retried until the number in the Error 
Count Field equals a maximum value that is deter- 
mined by the type of device and whether the device 
is involved in reading or writing data. When this max- 
imum value is reached, the error is considered uncor- 
rectable and the affected error routine causes a branch 
to be taken to the Error Control routine. 

If the error is corrected, the affected iocs error 
routine places the relevant iorw on the bottom of the 
appropriate File List with its Traffic Bit set off. 
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Appendixes 



Appendix A. Shared Input /Output Areas 

Two programming schemes that allow an input and an 
output file to share the same input/output areas are 
discussed in this section. 

Two File/Three Area Overlap Programming 

A programming scheme that allows one input and one 
output file sharing the same three input/output areas 
to be processed in a manner that provides for the 
overlapping of read/write and processing operations 
is discussed in the paragraphs that follow. This scheme 
allows records to be read into, processed in, and writ- 
ten out of the same input/output area. 

Note: This scheme is applicable only to fixed length 
Form 1 records. For other record forms, the user (in 
the process section) is responsible for blocking and 
deblocking of blocked records and for the insertion 
of the groupmark-wordmark in the correct position 
before issuing the put macro-instruction. 

To use this scheme, the program must be initialized 
as follows: (All labels used in this example are for 
illustrative purposes only.) 

1. Two files, one an input file labeled infile, one 
an output file labeled outfile, are defined. 

2. Three input/output areas, labeled areaI, area2, 
and area3, respectively, are defined. 

3. Three iorw's are generated, and one is labeled. 
Two of the lORw's are generated by means of the dtf 
lOAREAS entry included in the dtf statement defining 
infile, with areaI and area2 as its first and second 
operands. The third iorw is generated and labeled by 
means of the dtf ioareas entry included in the state- 
ment defining outfile, with areaS as its first operand 
and ouTioRW as its fourth operand. 

4. INFILE and outfile are opened (see Lines 1 and 
2 of Figure 119). 

5. The Traffic Bit of the iorw labeled outiorwa is 
set OFF (see Line 3). 

Once the program has been initialized, the two files 
are processed as follows : 

1. The IOCS is requested to make the next logical 
record from infile available in the specified input/ 
output area (see Line 4). 

2. The last record made available by the iocs is 
processed ( see Line 5 ) . 

3. The program is taken out of Priority Alert (see 
Line 6). 

4. The address of the low-order position of the Link 
Field of the iorw on the top of the File List associ- 
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Figure 119. Two File/Three Area Overlap Programming 

ated with infile is stored in index register 15 (see 
Line?). 

5. The IORW on the top of the File List associated 
with infile is removed from that list and the next 
IORW on the list (if any) is moved to the top of the 
list (see Line 8). 

6. The address of the File List Origin associated 
with OUTFILE is placed in the File List Address Field 
of the IORW that was removed from the File List asso- 
ciated with INFILE by Step 5 (see Line 9). 

7. The IORW that was at the top of the File List as- 
sociated with OUTFILE (if any) is linked to the iorw 
that is to be placed on the File List associated with 
OUTFILE by Step 8 (see Line 10). 

8. The IORW that was removed from the File List 
associated with infile by Step 5 is placed at the top 
of the File List associated with outfile (see Line 11). 

9. The x-control fields of the iorw's linked to the 
File List of outfile are initialized by the System 
Monitor ( see Lines 12 and 13 ) . 

10. The IOCS is requested to write the last record 
processed by the using program on outfile (see 
Line 14). 

11. The program is taken out of Priority Alert (see 
Line 15). 
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12. The address of the iorw on the top of the File 
List associated with outfile is stored in index register 
15 (see Line 16). 

13. The IORW on the top of the File List associated 
with OUTFILE is removed from that list and the next 
IORW on the list (if any) is moved to the top of the 
list ( see Line 17 ) . 

14. The IORW that was at the top of the File List 
associated with infile (if any) is linked to the iorw 
that is to be placed on the File List associated with 
infile by Step 15 (see Line 18). 

15. The IORW that was removed from the File List 
associated with outfile by Step 13 is placed at the 
top of the File List associated with infile (see Line 
19). 

16. The address of the File List Origin associated 
with INFILE is placed in the File List Address Field of 
the IORW that was removed from the File List as- 
sociated with OUTFILE by Step 13 (see Line 20). 

17. The x-control fields of the iorw's linked to the 
File List of infile are initialized by the System Moni- 
tor (see Lines 21 and 22). 

18. A branch is executed to Step 1 (see Line 23). 

Two File/Two Area Overlap Programming 

A programming scheme that allows one input file and 
one output file that share the same two input/output 
areas to be processed in a manner that provides for 
the overlapping of read/write and processing opera- 
tions is discussed in the material that follows. This 
scheme is efficient if the time required to process a 
record read by the iocs is relatively short compared 
to the time required to read the record (get) from 
the input file or write the record (put) on the output 
file. This scheme is only applicable to files made up of 
unblocked records. 

To use this scheme, the program is initialized as 
follows: (All labels used in this example are for illus- 
trative purposes only. ) 

1. Two files, one an input file labeled infile, the 
other an output file labeled outfile, are defined. 

2. Two input/output areas, one labeled areaI, the 
other labeled area2, are defined. 

3. Two iorw's are generated and labeled: one by 
means of a dtf ioareas entry included in the dtf 
statement defining infile, with areaI as its first op- 
erand and iniorw as its fourth operand; the other by 
means of a dtf ioareas entry included in the dtf state- 
ment defining outfile, with area2 as its first operand 
and ouTiORW as its fourth operand. 

4. A one-position field labeled switch is defined, 

5. infile and outfile are opened (see Lines 1 and 
2 of Figure 120). 

Once the program has been initialized, the two files 
are processed as follows : 
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Figure 120. Two File/Two Area Overlap Programming 

1. The character A is placed in switch (see Line 3). 

2. The Traffic Bit in outiorwa is set off (see 
Line 4). 

3. The IOCS is requested to make the next logical 
record from infile available in the input/output area 
whose address appears as the B-address of the instruc- 
tion contained in iniorwa (see Line 5). 

4. The address of the input/output area which is 
the B-address of the instruction contained in iniorwa 
is saved in Field 11 of infile (see Line 6). 

5. The low-order address of area2 is made the B- 
address of the input/output instruction contained in 
iniorwa (see Line 7). 

6. A branch is executed to process if the sign of the 
contents of switch is minus (see Line 8). 

7. The sign of switch is changed (see Line 9). 

8. The IOCS is requested to make the next logical 
record from infile available, on a deferred basis, in 
the input/output area whose address appears as the 
B-address of the instruction contained in iniorwa ( see 
Line 10). 

9. The IOCS is requested to write on outfile the 
last record processed by the using program (see Line 
11). 

10. The address of the input/output area saved in 
Field 11 of infile is made the B-address of the input/ 
output instruction contained in outiorwa (see Line 
12). 

11. A branch is executed to process if the sign of 
the contents of switch is minus (see Line 13). 

12. The iocs is requested to write on outfile, on a 
deferred basis, the last record processed by the using 
program (see Line 14). 
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13. The address of the input/output area, which is 
the B-address of the outiorwa, is saved in Field 10 of 
OUTFILE (see Line 15). 

14. A branch is executed to the instruction on Line 
5 (see Line 16). 

15. The contents of the B-address register are placed 
in the instruction on Line 19 (see Line 17). 

16. The current data record is processed (see 
Line 18). 

17. A branch is executed to the address saved by 
the instruction on Line 17 (see Line 19). 

Appendix B. Modification of GET and 
PUT Macro-Instructions 

The coding generated by all get and put macro-in- 
structions includes the sequence of instructions shown 
in Figure 121. 
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Figure 121. GEx/ptrr Calling Sequences 

The instruction shown on Line 1 of Figure 121 
causes the user's program to be removed from Priority 
Alert and a branch to be executed to the Resident 
IOCS at /pet/. The label filename shown on Line 2 
must be the same label that appears as the operand of 
the dtf Header Line entry for the file. The character 
represented by the alpha symbol shown on Line 3 
becomes the d-character of the input/output opera- 
tion requested by the relevant get or put macro- 
instruction. If this operation is a read operation the 
Dd statement shown on Line 3 is assembled containing 
the character R. If this operation is a write operation 
the DC statement is assembled containing the char- 
acter W. The Dcw statement shown on Line 4 indicates 
whether the relevant get or put macro-instruction is 
a GET FiLE,DEFER or PUT FiLE,DEFER. The Statement is 
assembled containing an S if this is the case. It is 
assembled containing a blank character if this is not 
the case. 

The programmer may alter the d-character of the 
input/output operation discussed above. He may do 
this by placing in the operand field of the DC state- 
ment shown on Line 3 of Figure 121 one of the fol- 
lowing characters: 

CHARACTER RESULTANT INPUT/OUTPUT OPERATION 

$ Read to interrecord gap or end of core. 

X Write to end of core. 

Q Alter read instruction to a No Operation 

(NOP) instruction. 
V Alter write instruction to a No Operation 

(NOP) instruction. 



If the programmer changes the character iin the 
operand field of the dc statement shown in Figure 121 
to $ or X, he must also change the channel character 
in the iorw at the top of the File List associated with 
the affected file. This channel character is assembled 
(i.e., overlap mode, channel 1) or as an * 



as an 



(i.e., overlap mode, channel 2). This channel char- 
acter must be changed to a % (i.e., non-overlap mode, 
channel 1) or a □ (i.e., non-overlap mode, channel 2). 
The reason for this change is that Read/Write to End 
of Core operations must always be executed in non- 
overlap mode on the ibm 1410. This channel character 
must be altered before the modified get or put macro- 
instruction is encountered in the using program. 



Appendix C. IOCS Console Messages 

This section provides explanations of the iocs console 
messages that are of interest to programmers who use 
the IOCS. 



Error Messages 

All IOCS error messages conform to the format shown 
in Figure 122. 

The message number shown in Figure 122 is con- 
stant. The two-character mnemonic mm indicates the 
type of error that has occurred ( e.g., dc indicates that 
a Data Check has occurred). The bcd code of the 
Channel Status Character indicates which channel 
status indicator(s) have been turned on as a result 
of the error. If the input/output operation that re- 
sulted in the error was a tape read operation, the last 
field of the error message contains an integer equal 
to the number of characters transferred into core stor- 
age as a result of the operation. If the operation was a 
disk operation, the last field contains the relevant disk 
address, in the form shown in Figure 113. 

The various combinations of characters that may ap- 
pear in the error type and channel status character 
fields, and the explanation of the condition and sug- 
gested action, are contained in Figure 123. A descrip- 
tion of the meaning of these characters as they pertain 
to 1311 Disk Storage can be found in the publication 
Support of IBM 1311 Disk Storage Drives Under the 
Operating System. 



Tape Label Messages 

The IOCS provides three tape label messages. These 
messages are described in Figure 124. 
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Message 
Number 



10101 



Error 
Type 



I Channel Status 
I Character 



Input/Output 
Instruction 



xxxxxxxxxx 



Tape Input Record Length 
or Disk Address 



Figure 122. iocs Error Message Format 





1 Channel 
Errori Stotuj 
Type! Character 


Affected 
Input/Output 
Device Type 


Explanation 


Action 


Not Ready 


nrI 1 

1 

1 


Tape, 1301,2302, 
card reader, 
cord punch, 
printer 


The relevant device (e.g., module of 1301 Disk Storage) it 
not ready. 


Reody the device. 


NrI/ 


1301 or 2302 


The IBM 7631 File control ij not ready. 


Ready the 7631 . 


NR J 


1301 or 2302 


The oddressed occess mechanism is inoperative. 


Ready the access. 


Dota Check 


DC 4 


Tape, 1301, 2302, 
card reader, 
card punch, 
printer 


Tope Input Operation; (o) If record length is greater than 12 

characters a bockspoce followed by o read operation has been 

executed 99 times. 

(b) If record length is 12 characters or less, ten consecutive 

noise records have been read without changing the B-oddress 

of the affected Input instruction. This Indicates thot the 

relevant tope unit has been set to the wrong density. 

Tope Output Operation; A backspace, o skip and blank tape, 

and a write operotion hove each been executed, in sequence, 25 times. 

1301 or 2302: The relevant input/output operation has been re-executed 

4 times 

Cord Reader; The lost cord read is In error. 

Cord Punch; Machine parity error. The cord is not punched. 

Printer: Machine parity error. The line Is not printed. 


far None. 

(b) Set the relevant 
tope unit to the correct 
density, 

None. 

None. 

Run out cord deck and reload. 
Moke the card reader Ready. 
Moke the device Not Ready, 
then Ready. 

Moke the device Not Ready, 
then Ready. 


DC 5 


1301 or 2302 


The relevant input/output operation has been re-executed once. 


None. 


"^Z 


M 


Tape, 1301 or 2302 
card reader 


See "DC4"obove. 


See "DC4." 


DC '«' 


Tope 


See "DC4" above. 


See "DC4." 


Condition 


UC 8 


Cord punch, 
printer 


Card Punch: An incorrect cord has been punched. The erroneous 
cord has been selected into stacker 0. 

Printer: A tlmlr\g error or hammer fire check has occurred. The 
line is not printed. 


Moke the device Not Ready, 
then Reody. 

Moke the device Not Ready, 
then Ready. 


Wrong Length Record 


WL - 


Tape, 1301, 2302, 
cord reader, 
cord punch, 
printer 


Tope Input Operation; The input operotion has been re-executed 
9 times. 

Tope Output Operotion' The output operation has been re- 
executed 25 times. 

1301 or 2302: The input/output operation has been re-executed four times. 
Cord Reader (IBM 1402); The input operation has not been re- 
executed. 
Card Reader (IBM 1442); The last cord reod is In error. 

Card Punch; The output operation has not been re-executed. 
Printer; The output operation has not been re-executed. 


None. 

If the error persists on the 
some record, the progrom 
should be terminoted. 
None. 
None. 

Run out card deck and reload. 
Moke the cord reader Ready, 
None. 
None. 


WL (i 


Tape 


Tope Input Operation; The wrong-length record and input/output 
condition indicotorj hove been turned on. The tope operation has 
been re -executed 9 times. 


None, 


No Record 
Found 


NF Z 


1301 or 2302 


The input/output operation has been re-executed 4 times, the 
access mechonism has been recalibrated, and the operotion has 
been re-executed on additional four times. 


If the message is repeoted for 
the some record, the program 
should be terminated. 


No Track 
Found 


IT V 


1301 or 2302 


The relevant access mechanism has been recolibroted and the 
input/output operotion hos been re-executed one time. 


If the messoge is repeated for 
the some record, the program 
should be terminated. 


Mode 
Check 


MD 


V 


1301 or 2302 


Data chock, no transfer, and condition indicators have resulted 
from a 1301 or 2302 operation. 


None. 


Circuit 
Check 


CC 


8 


1301 or 2302 


A 7631 circuit check has occurred. This input/output operation 
hos been re-executed one time. 


None, 


CC Q 


1301 or 2302 


See "CCS," above. 


See "CC8," 


1301 Circuit Check 
Involld Operation 
Write Dlik Check 
Without Mode 


OP 9 


1301 or 2302 


The input/output operation has been re-executed one time. 


If the message Is repeated for 
the some record, the program 
should be terminoted. 


UNCTL FILE, 
5SF,d 


NT * 


Card Reoder 


Two UNCTL FILE, SSF,d macro-instructions hove been executed 
without on intervenir)g Read A Cord instruction that contoins 9 in 
the units position of its x-control field. Two Read A Card instruc- 
tions with 9 in the units position of their x-control fields hove 
been executed without on intervening UNCTL FILE,SSF,d Macro- 
instruction. 


None, 


Write 
Inhibit 


NT * 


1301 or 2302 


Write operotion wos attempted, but write inhibit switch on 763l 
is ON. 


Turn Switch OFF, or ternilnote 
program , 


Unknown 
Error 


UE P 


1301 or 2302 


The IOCS connot determine the exact nature of the error. 
It is looping on the operation that coused it. 


Termlnote program. 



Figure ] 23. Error Type — Channel Status Characters 
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Message 


Explonotion 


Operator Action 


10102cu xxxxx 


The block count of the affected input 
tape trailer label does not equal the 
block count accumulated for the reel 
by the IOCS, (cu is the channel and 
unit of the affected tape; xxxxx is the 
difference between the IOCS block 
count and the block count, on the 
reel.) 


None 


30101 cu 


One or more fields of the affected 
input tape header label do not match 
the corresponding field(s) of the File 
Table Extension used to check the 
label, (cu is the channel and unit 
of the affected tape.) 


The IOCS can be 
directed to accept 
the tape, or to re- 
execute the label 
check with a differ- 
ent reel mounted. 

1 . Press Inquiry 
Request key. 

2. To re-execute, 
enter $8R; to ac- 
cept, enter $8A. 

3. Press Inquiry 
Release key. 


3d102 cu 


The retention period of the relevant 
output tape header label indicates 
that the tope should not be written 
on. (cu is the channel and unit of 
the relevant tape.) 


The IOCS can be 
directed to accept 
the tape, or to 
retry the label 
check with a dif- 
ferent tape 
mounted. 

1 . Press Inquiry 
Request key. 

2. To re-execute, 
enter $8R; to ac- 
cept, enter $8A. 

3. Press Inquiry 
Release key. 



Figure 124. iocs Tape Label Messages 



Appendix D. Work Files 

A work file is used both as an input file and an output 
file. The capability to handle such a file is a feature of 
the IOCS. Only one dtf statement is required to define 
a work file, because the File Table generated by a dtf 
statement does not indicate whether the file is an input 
or an output file. However, the programmer must be 
careful to include all the dtf entries in the work file 
DTF statement that are appropriate to both an input 
and an output file of the relevant type (e.g., tape or 
disk). 

The IOCS determines whether a work file is to be 
considered an input or an output file when the file is 
opened by means of either the ioctl open,input or 
the ioctl open,output macro-instruction. For this rea- 
son, when the file is to be switched from an input file 
to an output file, or from an output to an input, the file 
must be closed by means of the appropriate ioctl 
CLOSE macro-instruction and then reopened. The ioctl 
OPEN macro-instruction used to reopen the file indi- 
cates the file's new status. 

Note 1: File table field 25, reel sequence number, 
is never reset by iocs. 



Note 2: When a Form 4 output file is closed, the 
input/output area may contain a group mark with 
word mark that must be cleared before the file can 
be reopened as an input file. Residual Block Char- 
acter-Counts indicate the high-order limits of the areas 
in which group marks with word marks appear. 



Appendix £. Modification of the 
File Table Extension 

The contents of the fields of the File Table Extension 
can be altered if the programmer wants: (a) an input 
header label to be checked against information other 
than that currently contained in the relevant File 
Table Extension (i.e., the information originally sup- 
plied by the dtf label entry and updated where ap- 
propriate by the iocs), or (b) an output header label 
to be written from information other than that cur- 
rently contained in the relevant File Table Extension. 
The following procedure can be used to alter the 
information contained in the fields of the File Table 
Extension: 

1. Before the aflFected file is opened, the user's pro- 
gram reads a card containing the desired information 
from the system's Standard Input Unit. (See the System 
Monitor publication.) The format of this card is left to 
the user's discretion. 

2. The desired information is then moved from the 
siu input area (i.e., the area whose high-order position 
is designated by /crd/) into the relevant field or fields 
of the File Table Extension. 

3. The aflFected file is opened by means of an ioctl 
open macro-instruction. The label is then checked or 
written by the iocs, using the new information con- 
tained in the File Table Extension. 



Appendix F. Simultaneous Peripheral 
Operation On Line (SPOOL) 

Simultaneous Peripheral Operation On Line (spool) 
in the 1410/7010 Operating System permits card-to- 
tape, tape-to-card, or tape-to-printer operations to be 
executed at the same time as a dependent program. 
One unit-record and one tape unit must be used for 
spool. Tape operations are executed in Move mode 
and odd parity. For details on spool see IBM 1410/ 
7010 Operating System; System Monitor, Form C28- 
0319. 

Any one of three types of programmed control for 
spool can be used. 

Type I carries out the above peripheral operations 
without blocking, unblocking, or editing the records. 

Type II permits the user to include editing routines 
that have no input/output operations. 
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Type III pei-mits the user to include editing routines 
that contain iocs macro-instructions. 

SPOOL operations are defined at System Generation 
(see IBM 1410/7010 Operating System; System Gen- 
eration, Form C28-0S52) . 
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